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ALTA, DD FE 


在 过 去 单 核 CPU 时 代 ， 单 任务 在 一 个 时 间 点 只 能 执行 单一 程序 ， 随 
着 多 核 CPU 的 发 展 ， 并 行程 序 开 发 就 显得 尤为 重要 。 








本 书 主要 介绍 基于 Java 的 并 行程 序 设计 基础 、 思 路 、 方 法 和 实战 。 
第 一 ， 立 足 于 并 发 程序 基础 ， 详 细 介绍 Java 中 进行 并 行程 序 设计 的 基本 
方法 。 第 二 ， 进 一 步 详 细 介 绍 JDK 中 对 并 行程 序 的 强大 支持 ， 帮 助 读者 
快速 、 稳 健 地 进行 并 行程 序 开 及 。 第 三 ， 详 细 讨 论 有 关 “ 锁 ”的 优化 和 提 
高 并 行程 序 性 能 级 别 的 方法 和 思路 。 第 四 ， 介 绍 并 行 的 基本 设计 模式 及 
Java 8 对 并 行程 序 的 支持 和 改进 。 第 五 ， 介 绍 高 并 及 框架 Akka 的 使 用 方 
法 。 最 后 ， 详 细 介 绍 并 行程 序 的 调试 方法 。 


本 书 内 容 丰 富 ， 实 例 典 型 ， 实 用 性 强 ， 适 合 有 一 定 Java 基 础 的 技术 
FRAR HE- 


关于 Java 与 并 行 
由 于 单 核 CPU 的 主 频 逐步 通 近 极限 ， 多 核 CPU 架 构成 为 了 一 种 必然 

的 技术 趋势 。 所 以 ， 多 线程 并 行程 序 便 显 得 越 来 越 重 要 。 并 行 计 算 的 一 
目前 服务 端 CPU 的 核心 数 








个 重要 应 用 场景 束 是 服务 端 编程 。 可 以 看 到 ， 
已 经 轻松 超越 10 核 心 ， 而 Java 显 然 已 经 成 为 当下 最 流行 的 服务 端 编程 语 
言 ， 因 此 熟悉 和 了 解 基于 Java 的 并 行程 序 开发 有 着重 要 的 实用 价值 。 


本 书 的 体系 结构 
本 书 立 足 于 实际 开发 ， 又 不 缺乏 理论 介绍 ， 力 求 通俗 易 懂 、 循 序 浙 





进 。 本 书 共 分 为 8 章 。 
第 1 章 主要 介绍 了 并 行 计算 中 相关 的 一 些 基 本 概念 ， 树 立 读者 对 并 
行 计算 的 基本 认识 ， 介 绍 了 两 个 重要 的 并 行 性 能 评估 定律 ， 以 及 Java 内 


存 模型 JMML。 

章 介 绍 了 Java 并 行程 序 开发 的 基础 ， 包 括 Java 中 Thread 的 基本 使 
用 方法 等 ， 也 详细 介绍 了 并 行程 序 容 易 引 发 的 一 些 错误 和 误 用 。 

主要 介绍 








第 2 章 介 





第 3 章 介 绍 了 JDK 内 部 对 并 行程 序 开发 的 支持 
JUC (Java.util.concurrent〉 中 一 些 工 具 的 使 用 方法 、 各 自 特 点 及 它们 的 


内 部 实现 原理 。 


第 4 章 介 绍 了 在 开发 过 程 中 可 以 进行 的 对 锁 的 优化 ， 也 进一步 简要 
描述 了 Java 虚 拟 机 层面 对 并 行程 序 的 优化 支持 。 此 外 ， 还 花费 一 定 篇 幅 
介绍 了 有 关 无 锁 的 计算 。 


第 5 章 介 绍 了 并 行程 序 设计 中 常见 的 一 些 设计 模式 以 及 一 些 典 型 的 
并 行 算法 和 使 用 方法 ， 其 中 包括 重要 的 Java NIO 和 AIO 的 介绍 。 


第 6 章 介 绍 了 Java 8 中 为 并 行 计 算 做 的 新 的 改进 ， 包 括 并 行 流 、 
CompletableFuture、StampedLock 和 LongAdder。 


第 7 章 主要 介绍 了 高 并 发 框架 Akka 的 基本 使 用 方法 ， 并 使 用 Akka 框 
染 实现 了 一 个 简单 的 粒子 群 算法 ， 模 拟 超 高 并 友 的 场景 。 








第 8 章 介 绍 了 使 用 Edlipse 进 行 多 线程 调试 的 方法 ， 并 演示 了 通过 
Eclipse 进行 多 线程 调试 重 现 ArrayList 的 线程 不 安全 问题 。 


本 书 特色 


本 书 的 主要 特点 如 下 。 


1. Mish. AHH, SAREE, et. BO 
都 各 目 有 鲜明 的 侧重 点 ， 有 利于 读者 快速 抓 住 重 点 。 

2. 理论 结合 实战 。 本 书 注重 实 成 ， 书 中 重要 的 知识 点 都 安排 了 代码 
实例 ， 帮 助 读 者 理解 。 同 时 也 不 怎 记 对 系统 的 内 部 实现 原理 进行 
深度 剖析 。 

3. 通俗 易 懂 。 本 书 尽量 避免 采用 过 于 理论 的 描述 方式 ， 简 单 的 白话 


文风 格 贯穿 全 书 ， 配 图 基本 上 为 手工 绘制 ， 降 低 了 理解 难度 ， 并 
尽量 做 到 读者 在 阅读 过 程 中 少 育 点 、 无 言 点 。 


适合 疝 读 人 和 群 


虽然 本 书 力求 通俗 ， 但 要 通读 本 书 并 取得 良好 的 学 习 效果 ， 要 求 读 
者 需要 具备 基本 的 Java 知 识 或 者 一 定 的 编程 经 验 。 因 此 ， 本 书 适合 以 下 
读者 : 


。 拥有 一 定 开 发 经 验 的 Java 平 台 开 及 人 员 (Java, Scala, JRuby 
等 ) 

o 软件 设计 师 、 架 构 师 

。 系统 调 优 人 员 

。 有 一 定 的 Java 编 程 基础 并 希望 进一步 加 深 对 并 行 的 理解 的 研发 人 
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本 书 的 约定 


本 书 在 叙述 过 程 中 ， 有 如 下 约定 : 


e 本 书 中 所 述 的 JDK 1.5、JDK 1.6、JDK 1.7、JDK 1.8 分 别 等 同 于 
JDK 5、JDK 6、JDK 7、JDK 8。 
。 如 无 特殊 说 明 ， 本 书 的 程序 、 示 例 均 在 JDK 1.7 环 境 中 运行 。 


联系 作者 


本 书 的 写作 过 程 远 比 我 想象 得 更 艰辛 ， 为 了 让 全 书 能 够 更 清楚 、 更 
正确 地 表达 和 论述 ， 我 经 历 了 很 多 个 不 虐 之 夜 ， 即 使 现在 回想 起 来 ， 我 
也 怒 不 住 会 打 个 备战 。 由 于 写作 水 平 的 限制 ， 书 中 难免 会 有 不 受 之 处 ， 
望 读 者 诉 解 。 


为 此 ， 如 果 读 者 有 任何 疑问 或 者 建议 ， 非 常 欢迎 大 家 加 入 QQ 群 
397196583， 一 起 探讨 学 习 中 的 困难 、 分 享 学 习 的 经 验 ， 我 期 待 与 大 家 
一 起 交流 、 共 同 进步 。 同 时 ， 也 希望 大 家 可 以 关注 我 的 博客 


http://www.uucode.net/. 
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bie EAHTEA 


当 你 打开 本 书 ， 也 许 你 正 试 图 将 你 的 应 用 改造 成 并 行 模式 运行 ， 也 
许 你 只 是 单纯 地 对 并 行程 序 感 兴趣 。 无 论 出 于 何 种 原因 ， 你 正 对 并 行 计 
算 充满 好 奇 、 疑 问 和 求知 欲 。 如 果 是 这 样 ， 那 就 对 了 ， 带 着 你 的 好 奇 和 
疑问 ， 让 我 们 一 起 授 游 并 行程 序 的 世界 ， 深 入 了 解 它们 完 竟 是 如 何 工作 
的 吧 ! 





MIRE, RERAN- RENEE. MEKKI NAA 
行 计算 必然 成 为 未 来 的 大 趋势 时 ，2014 年 底 ，Avoiding ping pong 论 坛 
上 ， 伟 大 的 Linus ” Torvalds 提 出 了 一 个 截然 不 同 的 观点 ， 他 说 :“ 忘 挥 那 
该 死 的 并 行 吧 ! ”( 原 文 : Give it up. The whole "parallel computing is the 


future" is a bunch of crock. ) 


1.1 何去何从 的 并 行 计算 


到 后 我 们 该 如 何 选择 呢 ? 本 节 的 目的 残 是 拨 云 见 日 。 


1.1.1 起 挥 那 该 死 的 并 行 


Linus Torvalds 是 一 个 传奇 式 的 人 物 ( 图 1.1) ， 是 他 给 出 了 Linux 的 
原型 ， 并 一 直 致 力 于 推广 和 发 展 Linux 系 统 。 他 在 1991 年 首先 在 网 络 上 
发 布 了 Linux 源 码 ， 从 此 一 发 而 不 可 收 。Linux 迅 速 凯 起 壮大 ， 成 为 目前 
使 用 最 广泛 的 操作 系统 之 一 。 





图 1-1 传奇 的 Linus Torvalds 


自 2002 年 起 ，Linus 就 决定 使 用 BitKeeper 作 为 Linux 内 核 开 发 的 版 本 
控制 工具 ， 以 此 来 维护 Linux 的 内 核 源码 。BitKeeper 是 一 套 分 布 式 版 本 
控制 软件 ， 它 是 一 套 商 用 系统 ， 由 BitMover 公 司 开 发 。2005 年 ， 
BitKeeper 宣 称 发 现 Linux 内 核 开 发 人 员 使 用 逆 癌 工程 来 试图 解析 
BitKeeper 内 部 协议 。 因 此 ， 决 定向 Linus 收 回 BitKeeper 授 权 。 尽 管 Linux 
核心 团队 与 BitMover 公 司 进 行 了 协商 ， 但 是 无 法 解决 他 们 之 间 的 分 卜 。 
因此 ，Linus 决 定 自 行 研 发 版 本 控制 工具 来 代替 BitKeeper。 于 是 ，Giti 黎 
生 了 。 








如 果 大 家 正在 使 用 Git， 我 相信 你 们 一 定 会 被 Git 的 魅力 所 折服 ， 如 
果 还 没有 了 解 过 Git， 那 么 我 强烈 建议 你 去 关注 一 下 这 多 优秀 的 产品 。 

而 正 是 这 位 传奇 人 物 ， 给 目前 红 红 火 火 的 并 行 计算 泌 了 一 大 盆 冷 
水 。 那 么 ， 并 行 计 算 完 竟 应 该 何去何从 呢 ? 








在 Linus 的 发 言 中 这 么 说 道 : 


Where the hell do you envision that those magical parallel algorithms 


would be used? 


The only place where parallelism matters is in graphics or on the server 
side, where we already largely have it. Pushing it anywhere else is just 


pointless. 





需要 有 多 么 奇 本 上 的 想象 力 才 能 想象 出 并 行 计算 的 用 武之 地 ? 


并 行 计算 只 有 在 图 像 处 理 和 服务 端 编程 2 个 领域 可 以 使 用 ， 并 且 它 
在 这 2 个 领域 确实 有 着 大 量 广泛 的 使 用 。 但 是 在 其 他 任何 地 方 ， 并 行 计 
算 坚 无 建树 ! 








So the whole argument that people should parallelize their code is 
fundamentally flawed. It rests on incorrect assumptions. It's a fad that has 


been going on too long. 
因此 ， 人 们 在 争论 是 否 应 该 将 他 们 的 代码 并 行 化 是 一 个 本 质 上 的 错 
误 。 这 完全 就 基于 一 个 错误 的 假设 .“ 并 行 ? 是 一 个 早 该 结束 的 时 旷 


ies 








看 了 这 上 段 较为 完整 的 表述 ， 大 家 应 该 对 Linus 的 观点 有 所 感触 ， 我 
对 此 也 表示 赞同 。 与 串 行 程序 不 同 ， 并 行程 序 的 设计 和 实现 弄 负 复杂， 
不 仅仅 体现 在 程序 的 功能 分 离 上 ， 多 线程 间 的 协调 性 、 乱 序 性 都 会 成 为 
程序 正确 执行 的 障碍 。 只 要 你 稍 不 留神 ， 就 会 失 之 坚 厘 ， 请 以 千里 ! 混 
乱 的 程序 难以 阅读 、 难 以 理解 ， 更 难以 调试 。 所 谓 并 行 ， 也 就 是 把 简单 
问题 复杂 化 的 典型 。 因 此 ， 只 有 “产子 ? 才 会 叫 圳 并行 就 是 未 来 (the 


crazies talking about scaling to hundreds of cores are just that - crazy) 。 








但 是 ，Linus 也 提出 了 两 个 特例 ， 那 就 是 图 像 处 理 和 服务 端 程序 古 
可 以 、 也 需要 使 用 并 行 技 术 的 。 仔 细 想 想 ， 为 什么 图 像 处 理 和 服务 端 程 
序 是 特例 呢 ? 





和 用 户 终 端 程序 不 同 ， 图 像 处 理 往往 拥有 极 大 的 计算 量 。 一 张 
1024x768 像 素 的 图 片 ， 包 含 多 达 78 万 6 十 多 个 像 系 。 即 使 将 所 有 的 像 系 
志 有 历 一 再 ， 也 得 花 不 少时 间 。 更 何况 ， 图 像 处 理 涉 及 大 量 的 矩阵 计算 。 
矩阵 的 规模 和 数量 都 会 非 第 大 。 面 对 如 此 密集 的 计算 ， 很 有 可 能 超过 单 
核 CPU 的 计算 能 力 ， 所 以 自然 需要 引入 多 核 计算 了 。 





而 服务 端 程序 与 一 般 的 用 户 终端 程序 相 比 ， 一 方面 ， 服 务 端 程序 需 
要 承受 很 重 的 用 户 访 问 压力 。 根 据 淘 宝 的 数据 ， 它 在 “ 双 十 一 ”一 天 ， 文 





付 宝 核 心 数据 库 集 群 处 理 了 41 亿 个 事务 ， 执 行 285 亿 次 SQL， 生 成 15TB 
日 志 ， 访 问 1931 亿 次 内 存 数据 块 ，13 亿 个 物理 读 。 如 此 密集 的 访问 ， 恺 
怕 任 何 一 台 单 机 都 难以 胜任 ， 因 此 ， 并 行程 序 也 就 自然 成 了 唯一 的 出 

路 。 另 一 方面 ， 服 务 端 程序 往往 会 比 用 户 终 端 程序 拥有 更 复杂 的 业务 模 
型 。 面 对 复杂 业务 模型 ， 并 行程 序 会 比 串 行程 序 更 容易 适应 业务 需求 ， 
更 容易 模拟 我 们 的 现实 世界 。 毕 竟 ， 我 们 的 世界 本 质 上 是 并 行 的 。 比 

如 ， 当 你 开 开 心心 去 上 学 的 时 候 ， 妈 妈 可 能 在 家 里 忙 着 家 务 ， 和 爸爸 在 外 
打工 赚钱 ， 一 家 人 其 乐 融融 。 如 果 有 一 天 ， 你 需要 使 用 你 的 计算 机 来 模 
拟 这 个 场景 ， 你 会 怎么 做 呢 ?” 如 果 你 就 在 一 个 线程 里 ， 既 做 了 你 自己 ， 
又 做 了 妈妈 ， 又 做 了 苑 爸 ， 显 然 这 不 是 一 种 好 的 解决 方案 。 但 如 果 你 使 
用 三 个 线程 ， 分 别 模拟 这 三 个 人 ， 一 切 看 起 来 又 是 那么 自然 ， 而 且 容 易 
被 人 理解 。 




















再 举 一 个 专业 点 的 例子 ， 比 如 基础 平台 Java 虚 拟 机 ， 虚 拟 机 除了 要 
执行 main 函 数 主 线程 外 ， 还 需要 做 JIT 编 译 ， 需 要 做 垃圾 回收 。 无 论 是 
main 函 数 、JIT 编 译 还 是 垃圾 回收 ， 在 虚拟 机 内 部 者 实现 为 单独 的 一 个 
线程 。 是 什么 使 得 虚拟 机 的 研发 人 员 这 么 做 昵 ?显然 ， 这 是 因为 建 模 的 
需要 。 因 为 这 里 的 每 一 个 任务 都 是 相对 独立 的 。 我 们 不 应 该 将 没有 关联 
的 业务 代码 拼凑 在 一 起 ， 分 离 为 不 同 的 线程 更 容易 理解 和 维护 。 因 此 ， 
使 用 并 行 也 不 完全 出 自 性 能 的 考虑 ， 而 有 了 时候 ， 我 们 会 很 自然 地 那么 
做 。 


1.1.2 可怕 的 现实 : 摩尔 定律 的 矢 效 


摩尔 定律 是 由 英特尔 创始 人 之 一 蕊 登 . 摩 尔 提出 来 的 。 其 内 容 为 : 
集成 电路 上 可 容纳 的 电 唱 体 〈“ 品 体 管 ) 数目 ， 约 每 隔 24 个 月 便 会 增加 一 


fi; 经 党 被 引用 的 “18 个 月 "， 是 由 英特尔 首席 执行 官 大 卫 : 聚 斯 所 说 : 
预计 18 个 月 会 将 怪 片 的 性 能 提高 一 倍 《〈“ 即 更 多 的 品 体 管 使 其 更 快 ) 。 


说 得 直 白 点 ， 就 是 每 18 个 月 到 24 个 月 ， 我 们 的 计算 机 性 能 就 能 翻 一 
Fo 


反 过 来 说 ， 就 是 每 过 18 个 月 到 24 个 月 ， 你 在 未 来 用 一 半 的 价钱 就 能 
买 到 和 现在 性 能 相同 的 计算 设备 了 。 这 听 起 来 是 一 件 多 么 激动 人 心 的 事 
情 呀 ! 


但 是 ， 摩 尔 定律 并 不 是 一 种 自然 法 则 或 者 物理 定律 ， 它 只 是 基于 
为 观测 数据 后 ， 对 未 来 的 预测 。 按 照 这 种 速度 ， 我 们 的 计算 能 力 将 会 搁 
照 指 数 速度 增长 ， 用 不 了 多 久 ， 我 们 的 计算 能 力 就 能 超越 < 上 种 ”了 ! 畅 
想 未 来 ， 基 于 强劲 的 超级 计算 机 ， 我 们 其 至 可 以 模拟 整个 宇宙 。 


w 


摩尔 定律 的 有 效 性 已 经 超过 半 个 世纪 了 ， 然 而 ， 在 2004 年 ，Intel 宣 
布 将 4GHz 芯 片 的 发 布 时 间 推 迟到 2005 年 ， 在 2004 年 秋季 ，Intel 宣 布 彻 
底 取 消 4GHz 计 划 (图 1.2) 。 





图 1.2 Intel CEO Barret 单 膝下 跪 对 取消 4GHz 感 到 抱歉 


是 什么 迫使 世界 顶级 的 科 拉 巳 尖 放 莽 4GHz 的 研发 呢 ?” 显 然 ， 束 目 
前 的 硅 电 路 而 言 ， 很 有 可 能 已 经 走 到 了 涉 。 我 们 的 制造 工艺 已 经 到 了 纳 
米 了 。1 纳 米 是 10* 米 ， 也 就 是 10 亿 分 之 一 米 。 这 已 经 是 一 个 相当 小 的 数 
字 了 。 就 目前 的 科技 术 平 而 言 ， 如 果 无 法 在 物质 分 子 层面 以 下 进行 工 
作 ， 那 么 也 许 4GHz 的 心 片 就 已 经 接近 了 理论 极限 。 因 为 即使 一 个 水 分 
子 ， 它 的 直径 也 有 0.4 纳 米 。 再 往 下 发 展 就 显得 有 些 困 难 。 当 然 ， 如 果 
我 们 使 用 完全 不 同 的 计算 理论 或 者 必 片 生产 工艺 ， 也 许 会 有 本 质 的 突 
破 ， 但 目前 还 没有 看 到 这 种 技术 被 大 规模 使 用 的 可 能 。 

















因此 ， 摩 尔 定律 在 CPU 的 计算 性 能 上 可 能 已 经 失效 。 虽 然 ， 现 在 
Intel 已 经 研制 出 了 4GHz 心 片 ， 但 可 以 看 到 ， 在 近 10 年 的 发 展 中 ，CPU 主 
频 的 提升 已 经 明显 遇 到 了 一 些 暂 时 不 可 逾越 的 瓶颈 。 


1.1.3 HEH: 不 断 地 前 进 


虽然 CPU 的 性 能 已经 几 近 止步 ， 长 达 半 个 世纪 的 摩尔 定律 受 然 倒 
地 。 但 是 这 依然 没有 阻挡 科学 家 和 工程 师 们 带领 我 们 不 断 向 前 的 脚步 。 


从 2005 年 开始 ， 我 们 已 经 不 再 追求 单 核 的 计算 速度 ， 而 着 迷 于 研究 
如 何 将 多 个 独立 的 计算 单元 整合 到 单独 的 CPU 中 ， 也 就 是 我 们 所 说 的 多 
核 CPU。 短 短 十 几 年 的 发 展 ， 家 用 型 CPU， 比 如 Intel ”i7 就 可 以 拥有 4 核 
心 ， 甚 至 8 核心 。 而 专业 服务 器 则 通常 可 以 配 有 几 个 独立 的 CPU， 每 一 
个 CPU 都 拥有 多 达 8 个 甚至 更 多 的 内 核 。 从 整体 上 看 ， 专 业 服 务 器 的 内 
核 总 数 甚至 可 以 达到 几 百 个 。 


非常 令 人 激动 ， 摩 尔 定 律 在 另外 一 个 侧面 又 生效 了 。 根 据 这 个 定 
律 ， 我 们 可 以 预测 ， 每 过 18 到 24 个 月 ，CPU 的 核心 数 就 会 翻 一 一。 用 不 
了 多 和 久 ， 拥 有 几 十 甚至 上 百 CPU 内 核 的 芯片 就 能 进入 千家 万 户 。 


顶级 计算 机 科学 家 唐纳德 . 尔 文 克 努 斯 (Donald Ervin Knuth) ， 如 
此 评价 这 种 情况 ， 在 我 看 来 ， 这 种 现象 (并 发 ) 或 多 或 少 是 由 于 硬件 
设计 者 已 经 无 计 可 施 了 导致 的 ， 他 们 将 摩尔 定律 失效 的 责任 推脱 给 软 
件 开发 者 。 








唐纳德 〈 图 1.3) 是 著名 计算 机 巨著 《计算 机 程序 设计 艺术 》 的 作 
者 。《 美 国 科学 家 》 和 杂志 曾 将 该 书 与 爱 因 斯 坦 的 《相对 论 》， 狄 拉克 的 
《量子 力学 》 和 理 碍 . 费 曼 的 《量子 电动 力学 》 等 书 并 列 为 20 世 纪 最 重 
要 的 12 本 物理 科学 类 专 论 书 之 一 。 





图 1.3 唐纳德 院士 


1.1.4 ”光明 或 是 黑暗 


根据 唐纳德 的 观点 ， 摩 尔 定律 本 应 该 由 便 件 开发 人 员 维持 。 但 是 ， 
很 不 仁 ， 硬 件 工程 师 似 乎 已 经 无 计 可 施 了 。 为 了 继续 保持 性 能 的 高 速 发 
展 ， 人 硬件 工程 师 就 破 天 殉 地 想 出 了 将 多 个 CPU 入 核 塞 进 一 个 CPU 里 的 奇 
妙 想 法 。 由 此 ， 并 行 计算 就 被 非常 自然 地 推广 开 来 ， 而 随 之 而 来 的 问题 
也 层出不穷 ， 程 序 员 的 黑暗 时 期 也 随 之 到 来 。 简 化 的 硬件 设计 方案 必然 
市 来 软件 设计 的 复杂 性 。 换 句 话 说， 软件 工程 师 正 在 为 硬件 工程 师 无 法 
完成 的 工作 负责 ， 因 此 ， 也 就 有 了 唐纳德 的 “他 们 将 摩尔 定律 失效 的 黄 
任 推脱 给 了 软件 开发 者 ”的 说 法 。 





所 以 ， 如 何 让 多 个 CPU 有 效 并 且 正 确 地 工作 也 就 成 为 了 一 门 技术 ， 
甚至 是 很 大 的 学 问 。 比 如 ， 多 线程 间 如 何 保 证 线程 安全 ， 如 何 正确 理解 
线程 间 的 无 序 性 、 可 见 性 ， 如 何 尽 可 能 提高 并 行程 序 的 设计 ， 又 如 何 将 
串 行 程序 改造 为 并 行程 序 。 而 对 并 行 计算 的 研究 ， 也 就 是 希望 在 这 片 黑 
暗中 带 来 光明 。 


1.2 ”你 必须 知道 的 几 个 概念 


现在 ， 并 行 计 算 显 然 已 经 成 为 一 门 正式 的 学 问 。 也 许 很 多 人 《包括 
Linus 在 内 ) ， 都 会 党 得 并 行 计 算 或 者 说 并 行 算 法 是 多 么 奇 范 。 但 现在 
我 们 也 不 得 不 承认 ， 在 东 些 领域 ， 这 些 算 法 还 是 有 用 武之 地 的 。 既 然 说 
服务 端 编程 还 是 大 量 需 要 并 行 计算 的 ， 而 Java 也 主要 占领 着 服务 端 市 
场 ， 那 么 对 Java 的 并 行 计算 的 研究 也 就 显得 非常 的 必要 。 但 首先 ， 我 想 
在 这 里 先 介 绍 几 个 重要 的 相关 概念 。 





























1.2.1 同步 (Synchronous) 和 异步 
(Asynchronous) 


同步 和 异步 通常 用 来 形容 一 次 方法 调用 。 同 步 方法 调用 一 旦 开始 ， 
调用 者 必须 等 到 方法 调用 返回 后 ， 才 能 继续 后 续 的 行为 。 异 步 方法 调用 
更 像 一 个 消息 传递 ， 一 旦 开始 ， 方 法 调用 就 会 立即 返回 ， 调 用 者 就 可 以 
继续 后 续 的 操作 。 而 异步 方法 通常 会 在 另外 一 个 线程 中 “真实 ”地 执行 。 
整个 过 程 ， 不 会 阻碍 调用 者 的 工作 。 图 1.4 显 示 了 同步 方法 调用 和 异步 
方法 调用 的 区 别 。 对 于 调用 者 来 说 ， 异 步调 用 似乎 是 一 瞬间 就 完成 的 。 
如 果 异 步调 用 需要 返回 结果 ， 那 么 当 这 个 异步 调用 真实 完成 时 ， 则 会 通 
知 调用 者 。 
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图 1.4 同步 和 异步 方法 调用 


打 个 比方 ， 比 如 我 们 去 购物 ， 如 有 果 你 去 商场 实体 店 买 一 台 空 调 ， 当 
你 到 了 商场 看 中 了 一 球 空 调 ， 你 就 想 售货员 下 单 。 售 货 员 去 仓库 帮 你 调 
配 物 品 。 这 天 你 热 得 实在 不 行 了 ， 束 催 着 商家 赶紧 给 你 送 贷 ， 于 是 你 束 
等 在 商店 里 ， 候 着 他 们 ， 直 到 商家 把 你 和 空调 一 起 送 回 家 ， 一 次 愉快 的 
购物 就 结束 了 。 这 就 是 同步 调用 。 








不 过 ， 如 果 我 们 赶 时 和 又， 就 坐 在 家 里 打开 电脑 ， 在 网 上 订购 了 一 全 
空调 。 当 你 完成 网 上 文 付 的 时 候 ， 对 你 来 说 购物 过 程 已 经 结束 了 。 虽 然 
空调 还 没 送 到 家 ， 但 是 你 的 任务 都 已 经 完成 了 。 商 家 接 到 了 你 的 订单 
后 ， 就 会 加 紧 安 排 送 货 ， 当 然 这 一 切 已经 跟 你 无 天 了 。 你 已 经 文 付 完 
成 ， 想 干什么 就 能 去 干什么 ， 出 去 溜 几 圈 都 不 成 问题 ， 等 送 货 上 门 的 时 
候 ， 接 到 商家 的 电话 ， 回 家 一 趟 签收 就 完事 了 。 这 就 是 异步 调用 。 














1.2.2 ”并 及 (Concurrency) 和 并 行 
(Parallelism ) 





并 有 友和 并 行 是 两 个 非常 容易 和 被 混 消 的 概念 。 它 们 都 可 以 表示 两 个 或 
者 多 个 任务 一 起 执行 ， 但 是 偏重 点 有 些 不 同 。 并 发 偏重 于 多 个 任务 交 蔡 

















执行 ， 而 多 个 任务 之 间 有 可 能 还 是 串 行 的 。 而 并 行 是 真正 意义 上 的 “ 同 
时 执行 ”。 图 1.5 很 好 地 诠释 了 这 点 。 


ee ee >> >| 
-= -> 

| 

| 

| 
IAS AR. 


图 1.5 并 发 和 并 行 








严格 意义 上 来 说 ， 并 行 的 多 个 任务 是 真实 的 同时 执行 ， 而 对 于 并 发 
来 次 ， 这 个 过 程 只 是 交 蔡 的 ， 一 会 儿 运 行 任务 A 一 会 儿 执行 任务 B， 系 
统 会 不 集 地 在 两 者 间 切 换 。 但 对 于 外 部 观察 者 来 说 ， 即 使 多 个 任务 之 间 
古 串 行 并 发 的 ， 也 会 造成 多 任务 间 是 并 行 执行 的 错觉 。 





这 两 种 情况 在 生活 中 都 很 常见 。 我 曾经 去 贡 山 旅游 过 两 次 ， 黄 山 风 
景 奇特 ， 有 大 “ 五 后 归来 不 看 山 ， 黄 山 归 来 不 看 项 ”的 美称 。 只 要 去 过 黄 
山 的 人 都 应 该 知道 ， 导 游 时 常 挂 在 嘴 边 的 “走路 不 看 景 ， 看 景 不 走路 ”。 
因为 黄山 项 上 经 常 下 雨 ， 地 面 湿 滑 ， 地 形 险峻 。 如 果 边 走边 看 ， 跌 倒 探 
伤 那 是 第 有 的 事 。 安 全 起 见 ， 束 要 求 旅游 在 看 景 的 时 候 ， 能 够 停 下 肢 
步 ， 走 路 的 时 候 能 够 专心 看 着 地 面 ， 管 好 双 脚 。 这 就 是 “并 发 ”。 它 
AEA’ ABARAT WIN KA, AAMT, ABATE A 
是 “同时 在 看 景 和 走路 ”。 























那么 在 黄山 上 真正 的 “并 行 ?应 该 是 什么 样子 呢 ? 聪明 的 同学 应 该 可 
以 想到 ， 那 就 是 坐 线 车 上 山 。 线 车 可 以 代 苦 步行 ， 你 坐 在 线 车 上 才能 
心 欣 蓉 沿途 的 风景 ,“ 走 路 "这些 事情 全 部 交 给 缆车 去 完成 就 好 了 。 


实际 上 ， 如 果 系 统 内 只 有 一 个 CPU， 而 使 用 多 进程 或 者 多 线程 任 
务 ， 那 么 真实 环境 中 这 些 任务 不 可 能 是 真实 并 行 的 ， 毕 竞 一 个 CPU 一 次 
只 能 执行 一 条 指令 ， 这 种 情况 下 多 进程 或 者 多 线程 就 是 并 发 的 ， 而 不 是 
并 行 的 (操作 系统 会 不 停 切 换 多 个 任务 ) 。 真 实 的 并 行 也 只 可 能 出 现在 
拥有 多 个 CPU 的 系统 中 《比如 多 核 CPU) 。 


由 于 并 发 的 最 终 效果 可 能 是 和 并 行 一 样 的 ， 因 此 ， 如 有 果 没 有 特别 的 
需要 ， 我 在 本 书 中 不 会 特别 强调 两 者 的 区 别 。 


1.2.3 KAK 


临界 区 用 来 表示 一 种 公共 资源 或 者 说 是 共 孚 数据 ， 可 以 被 多 个 线程 
使 用 。 但 是 每 一 次 ， 只 能 有 一 个 线程 使 用 它 ， 一 旦 临界 区 资源 被 占用 ， 
其 他 线程 要 想 使 用 这 个 资源 ， 吏 必须 等 符 。 


比如 ， 在 一 个 办 公 室 里 有 一 台 打 印 机 。 打 印 机 一 次 只 能 执行 一 个 任 
务 。 如 采 小 王 和 小 明 同时 需要 打印 文件 ， 很 显然 ， 如 果 小 王 匈 下 及 了 打 
印 任务 ， 打 印 机 就 开始 打印 小 王 的 文件 。 小 明 的 任务 吏 只 能 等 待 小 王 打 
印 结束 后 才能 打印 。 这 里 的 打印 机 束 是 一 个 临界 区 的 例子 。 








在 并 行程 序 中 ， 临 界 区 资源 是 保护 的 对 象 ， 如 果 意 外 出 现 打印 机 同 
时 执行 两 个 打印 任务 ， 那 么 最 可 能 的 结果 就 是 打印 出 来 的 文件 就 会 是 损 
坏 的 文件 。 它 既 不 是 小 王 想 要 的 ， 也 不 是 小 明 想 要 的 。 





1.2.4 阻塞 (Blocking) 和 非 阻塞 
(Non-Blocking ) 





咀 窒 和 非 阻 暑 通 常用 来 形容 多 线程 间 的 相互 影响 。 比 如 一 个 线程 占 
用 了 临界 区 资源 ， 那 么 其 他 所 有 需要 这 个 资源 的 线程 就 必须 在 这 个 临界 
区 中 进行 等 待 。 等 待 会 导致 线程 挂 起 ， 这 种 情况 就 是 阻 坚 。 此 时 ， 如 果 
占用 资源 的 线程 一 直 不 愿意 释放 资源 ， 那 么 其 他 所 有 阻 竖 在 这 个 临界 区 
上 的 线程 都 不 能 工作 。 








非 阻塞 的 意思 与 之 相反 ， 它 强调 没有 一 个 线程 可 以 妨碍 其 他 线程 执 
行 。 所 有 的 线程 都 会 尝试 不 断 前 癌 执 行 。 有 关 这 个 概念 ， 将 在 本 章 “ 并 
发 级 别 一 节 中 做 更 详细 的 描述 。 


1.2.5 i (Deadlock) . {Lith 
(Starvation) 和 活 锁 CLivelock) 


死 锁 、 饥 饿 和 活 锁 都 属于 多 线程 的 活跃 性 问题 。 如 条 发 现 上 述 几 种 
情况 ， 那 么 相关 线程 可 能 就 不 再 活跃 ， 也 惑 说 它 可 能 很 难 再 继续 往 下 执 
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死 锁 应 该 是 最 糟糕 的 一 种 情况 了 当然 ， 其 他 几 种 情况 也 好 不 到 哪 
里 去 ) ， 图 1.6 显 示 了 一 个 死 锁 的 发 生 。 


图 1.6 死 锁 的 发 生 


A、B、C、DD 四 辆 小 车 在 这 种 情况 下 都 无 法 继续 行驶 了 。 它 们 彼此 
之 间 相互 占用 了 其 他 车 辆 的 车 道 ， 如 果 大 家 都 不 愿意 释放 自己 的 车 道 ， 
那么 这 个 状态 将 永远 维持 下 去 ， 谁 都 不 可 能 通过 。 死 锁 是 一 个 很 严重 
的 ， 并 且 应 该 避免 和 时 时 小 心 的 问题 ， 我 们 将 安排 在 “ 锁 的 优化 与 注意 
事项 ”一 章 中 进行 更 详细 的 讨论 。 


饥饿 是 指 茶 一 个 或 者 多 个 线程 因为 种 种 原因 无 法 获得 所 需要 的 资 
源 ， 导 致 一 直 无 法 执行 。 比 如 筷 的 线程 优先 级 可 能 太 低 ， 而 高 优先 级 的 
线程 不 断 抢 后 它 需要 的 资源 ， 导 致 低 优 先 级 线程 无 法 工作 。 在 目 然 界 
中 ， 母 乌 喂 食 雏 乌 时 ， 很 容易 出 现 这 种 情况 。 由 于 和 雏 乌 很 多 ， 食 物 可 能 
有 限 ， 委 乌 之 间 的 食物 竞争 可 能 非常 历 害 ， 小 骏 乌 因为 经 阁 抢 不 到 食 
物 ， 有 可 能 会 极 饿 死 。 线 程 的 饥饿 也 非常 类 似 这 种 情况 。 另 外 一 种 可 能 
是 ， 茶 一 个 线程 一 直 占 着 关键 资源 不 放 ， 导 致 其 他 需要 这 个 资源 的 线程 
无 法 正常 执行 ， 这 种 情况 也 是 饥饿 的 一 种 。 与 死 锁 相 比 ， 饥 猴 还 是 有 可 
能 在 未 来 一 段 时 间 内 解决 的 《比如 高 优先 级 的 线程 已 经 完成 任务 ， 不 再 





疯狂 的 执行 ) 。 





活 锁 是 一 种 非常 有 趣 的 情况 。 不 知道 大 家 是 不 是 有 过 到 过 这 人 么 一 种 
场景 ， 当 你 要 坐 电梯 下 楼 ， 电 标 到 了 ， 门 开 了 ， 这 时 你 正 准 备 出 去 。 但 
很 不 巧 的 是 ， 门 外 一 个 人 挡 着 你 的 去 路 ， 他 想 进来 。 于 是 ， 你 很 绅士 地 
靠 左 走 ， 避 让 对 方 。 同 时 ， 对 方 也 是 非常 绅士 地 ， 但 他 靠 右 走 而 望 避 让 
Ko ZR, UAV RES. Pre, MIRARI T al, ABS 
快 避 让 对 方 ， 你 立即 向 右边 走 ， 同 时 ， 他 立即 向 左边 走 。 结 果 ， 叉 撞 上 
T! 不 过 介 于 人 类 的 智能 ， 我 相信 这 个 动作 重复 2、3 次 后 ， 你 应 该 可 以 
顺利 解决 这 个 问题 。 因 为 这 个 时 候 ， 大 家 都 会 本 能 的 对 视 ， 进 行 交 流 ， 
保证 这 种 情况 不 再 发 生 。 




















但 如 果 这 种 情况 发 生 在 两 个 线程 间 可 能 就 不 会 那么 羊 运 了 。 如 宋 线 
程 的 智力 不 够 ， 且 都 秉承 着 “谦让 ”的 原则 ， 主 动 将 资源 释放 给 他 人 使 
用 ， 那 么 就 会 出 现 资源 不 断 在 两 个 线程 中 跳动 ， 而 没有 一 个 线程 可 以 同 
时 拿 到 所 有 资源 而 正常 执行 。 这 种 情况 就 是 活 锁 。 


1.3 FERH 


由 于 临界 区 的 存在 ， 多 线程 之 间 的 并 发 必须 受到 控制 。 根 据 控制 并 
发 的 琐 上 略 ， 我 们 可 以 把 并 发 的 级 别 进行 分 类 ， 大 致 上 可 以 分 为 阻塞 、 无 
饥饿 、 无 障碍 、 无 锁 、 无 等 待 几 种 。 





1.3.1 [HE (Blocking) 


AS BFE ERA ZEN, AKA CE ACRE PER ZA, SU BG PE TCI 
继续 执行 。 当 我 们 使 用 synchronized 关 键 字 ， 或 者 重 入 锁 时 〈 我 们 将 在 
第 2、3 章 介绍 这 两 种 技术 ) ， 我 们 得 到 的 就 是 阻 豆 的 线程 。 


无 论 是 synchronized 或 者 重 入 锁 ， 都 会 试图 在 执行 后 续 代 码 前 ， 得 
到 临界 区 的 锁 ， 如 果 得 不 到 ， 线 程 就 会 被 挂 起 等 待 ， 直 到 占有 了 上 所 需 资 
源 为 止 。 


1.3.2 ”无 饥饿 (Starvation-Free ) 


如 果 线 程 之 间 是 有 优先 级 的 ， 那 么 线程 调度 的 时 候 总 是 会 倾向 于 满 
足 高 优先 级 的 线程 。 也 就 说 是 ， 对 于 同一 个 资源 的 分 配 ， 是 不 公平 的 ! 
如 图 1.7 所 示 ， 显 示 了 非 公平 与 公平 两 种 情况 〈 五 角 星 表示 高 优先 级 线 
程 》。 对 于 非 公平 的 锁 来 说 ， 系 统 允许 高 优先 级 的 线程 插队 。 这 样 有 可 
能 导致 低 优 和 级 线程 产生 饥饿 。 但 如 果 锁 是 公平 的 ， 满 足 先 来 后 到 ， 那 
么 饥饿 就 不 会 产生 ， 不 管 新 来 的 线程 优先 级 多 高 ， 要 想 获得 资源 ， 就 必 











须 乖 乖 排 队 。 那 么 所 有 的 线程 都 有 机 会 执行 。 
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图 1.7 公平 与 非 公平 锁 


1.3.3 ”无 障 但 (Obstruction-Free) 











无 障碍 是 一 种 最 弱 的 非 阻塞 调度 。 两 个 线程 如 果 是 无 障碍 的 执行 ， 
那么 他 们 不 会 因为 临界 区 的 问题 导致 一 方 被 挂 起 。 换 言 之 ， 大 家 都 可 以 
大 摇 大 摆 地 进入 临界 区 了 。 那 么 如 果 大 家 一 起 修改 共 孚 数据 ， 把 数据 改 
坏 了 可 怎么 办 呢 ? 对 于 无 障碍 的 线程 来 说 ， 一 旦 检 训 到 这 种 情况 ， 它 就 
会 立即 对 自己 所 做 的 修改 进行 回 深 ， 确 保 数 据 安全 。 但 如 果 没 有 数据 苋 
和 搜 友 生 ， 那 么 线程 就 可 以 顺利 完成 自己 的 工作 ， 走 出 临界 区 。 








如 果 说 阻 窗 的 控制 方式 是 莫 观 集 略 。 也 束 是 说 ， 系 统 认为 两 个 线程 
之 间 很 有 可 能 发 生 不 幸 的 冲突 ， 因 此 ， 以 保护 共 孚 数据 为 第 一 优先 级 。 
相对 来 说 ， 非 阻 窄 的 调度 束 是 一 种 乐观 的 策略 。 它 认为 多 个 线程 之 间 很 
有 可 能 不 会 及 生 冲 突 ， 或 者 说 这 种 概率 不 大 。 因 此 大 家 都 应 该 无 障碍 的 
执行 ,但 是 一 旦 检测 到 冲突 ， 就 应 该 进行 回 深 。 








从 这 个 策略 中 也 可 以 看 到 ， 无 障碍 的 多 线程 程序 并 不 一 定 能 顺畅 的 
运行 。 因 为 当 临 春 区 中 存在 严重 的 神 突 时 ， 所 有 的 线程 可 能 都 会 不 断 地 
回 深 上 自己 的 操作 ， 而 没有 一 个 线程 可 以 走出 临界 区 。 这 种 情况 会 影响 系 
统 的 正常 执行 。 所 以 ， 我 们 可 能 会 非常 希望 在 这 一 堆 线 程 中 ， 人 至 少 可 以 
有 一 个 线程 能 够 在 有 限 的 时 间 内 完成 自己 的 操作 ， 而 退出 临界 区 。 人 至 少 
这 样 可 以 保证 系统 不 会 在 临界 区 中 进行 无 限 的 等 符 。 








一 种 可 行 的 无 障碍 实现 可 以 依赖 一 个 “一 致 性 标记 ?来 实现 。 线 程 在 
操作 之 前 ， 先 读 取 并 保存 这 个 标记 ， 在 操作 完成 后 ， 再 次 读 取 ， 检 查 这 
个 标记 是 人 否 补 更改 过， 如 宁 两 者 是 一 致 的 ， 则 说 明 资 源 访 问 没有 冲突 。 
如 琳 不 一 至， 则 说 明 资 源 可 能 在 操作 过 程 中 与 其 他 写 线程 冲突 ， 需 要 重 
试 操作 。 而 任何 对 资源 有 修改 操作 的 线程 ， 在 修改 数据 前 ， 都 需要 更 新 
这 个 一 致 性 标记 ， 表 示 数 据 不 再 安全 。 











1.3.4 S (Lock-Free ) 





无 锁 的 并 行 都 是 无 障碍 的 。 在 无 锁 的 情况 下 ， 所 有 的 线程 都 能 尝试 
对 临界 区 进行 访问 ， 但 不 同 的 是 ， 无 锁 的 并 发 保证 必然 有 一 个 线程 能 够 
在 有 限 步 内 完成 操作 离开 临界 区 。 





在 无 锁 的 调用 中 ， 一 个 典型 的 特点 是 可 能 会 包含 一 个 无 穷 循 环 。 在 
这 个 循环 中 ， 线 程 会 不 断 尝 试 修改 共 至 变量 。 如 果 没 有 冲突 ， 修 改 成 
功 ， 那 么 程序 退出 ， 人 否则 继续 答 试 修改 。 但 无 论 如 何 ， 无 锁 的 并 行 总 能 
保证 有 一 个 线程 是 可 以 胜出 的 ， 不 至 于 全 摆 履 没 。 至 于 临界 区 中 竞争 失 
败 的 线程 ， 它 们 则 必须 不 断 重 试 ， 直 到 自己 获胜 。 如 果 运 气 很 不 好 ， 总 
是 答 试 不 成 功 ， 则 会 出 现 类 似 饥饿 的 现象 ， 线 程 会 停止 不 前 。 








下 面 就 是 一 段 无 锁 的 示意 代码 ， 如 采 修 改 不 成 功 ， 那 么 循环 永远 不 


while (!atomicVar.compareAndSet(localVar, localVar+1)) { 


localVar = atomicVar.get(); 








有 关 无 锁 ， 我 们 将 安排 在 “ 锁 的 优化 与 注意 事项 ”一 章 中 详细 介绍 。 
Fey e 
1.3.5 ”无 等 符 (Wait-Free) 


无 锁 只 要 求 有 一 个 线程 可 以 在 有 限 步 内 完成 操作 ， 而 无 等 待 则 在 无 
锁 的 基础 上 更 进一步 进行 扩展 。 它 要 求 所 有 的 线程 部 必须 在 有 限 步 内 完 
成 ， 这 样 融 不 会 引起 饥 狐 问题 。 如 果 限 制 这 个 步骤 上 限 ， 还 可 以 进一步 
分 解 为 有 界 无 等 每 和 线程 数 无 关 的 无 等 等 几 种 ， 它 们 之 间 的 区 别 只 是 对 
循环 次 数 的 限制 不 同 。 








一 种 典型 的 无 等 待 结 构 就 是 RCU (Read-Copy-Update) 。 它 的 基本 
思想 是 ， 对 数据 的 读 可 以 不 加 控制 。 因 此 ， 所 有 的 读 线 程 都 是 无 等 待 
的 ， 它 们 既 不 会 被 锁定 等 待 也 不 会 引起 任何 冲突 。 但 在 写 数据 的 时 候 ， 
先 取得 原始 数据 的 副本 ， 接 着 只 修改 副本 数据 (这 就 是 为 什么 读 可 以 不 
加 控制 ) ， 修 改 完成 后 ， 在 合适 的 时 机 回 写 数据 。 

















14 有 天 开行 的 两 个 里 要 定律 


有 关 为 什么 要 使 用 并 行程 序 的 问题 在 之 前 已 经 进行 了 简单 的 探讨 。 
总 的 来 说 ， 最 重要 的 应 该 是 出 于 两 个 目的 。 第 一 ， 为 了 获得 更 好 的 性 
能 ， 第 二 ， 由 于 业务 模型 的 需要 ， 确 实 需要 多 个 执行 实体 。 在 这 里 ， 我 
将 更 加 关注 于 第 一 种 情况 ， 也 就 是 有 关 性 能 的 问题 。 将 串 行 程序 改造 为 
并 发 ， 一 般 来 说 可 以 提供 程序 的 整体 性 能 ， 但 是 究竟 能 提高 多 少 ， 甚 至 
说 究竟 是 否 真 的 可 以 提高 ， 还 是 一 个 需要 研究 的 问题 。 目 前 ， 主 要 有 两 
个 定律 对 这 个 问题 进行 解答 ， 一 个 是 Amdahl 定 律 ， 另 外 一 个 是 
Gustafson 定 律 。 

















1.4.1 Amdahl 定 律 


Amdahl 定 律 是 计算 机 科学 中 非常 重要 的 定律 。 它 定义 了 串 行 系统 
并 行 化 后 的 加 速 比 的 计算 公式 和 理论 上 限 。 


加 速 比 定 义 : 加 速 比 = 优化 前 系统 耗 时 /优化 后 系统 耗 时 


即 ， 所 谓 加 速 比 ， 就 是 优化 前 的 耗 时 与 优化 后 耗 时 的 比值 。 加 速 比 
越 高 ， 表 明 优 化 效果 越 明 显 。 图 1.8 显 示 了 Amdahl 公 式 的 推导 过 程 ， 其 
中 n 表 示 处 理 器 个 数 ，T 表 示 时 间 ，T1 表 示 优 化 前 耗 时 〈 也 就 是 只 有 1 个 
处 理 器 时 的 耗 时 ) ，Tn 表 示 使 用 n 个 处 理 器 优化 后 的 耗 时 。F 是 程序 中 只 
能 串 行 执行 的 比例 。 
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图 1.8 Amdah1 公 式 的 推导 


根据 这 个 公式 ， 如 宁 CPU 处 理 器 数量 趋 于 无 穷 ， 那 么 加 速 比 与 系统 
的 串 行 化 率 成 反比 ， 如 果 系 统 中 必须 有 50% 的 代码 串 行 执行 ， 那 么 系统 
的 最 大 加 速 比 为 2。 

假设 有 一 程序 分 为 以 下 步骤 执行 ， 每 个 执行 步骤 花费 100 个 时 间 单 
位 。 其 中 ， 只 有 步骤 2 和 步骤 5 可 以 进行 并 行 ， 步 骤 1、3、4 必 须 串 行 ， 
如 图 1.9 所 示 。 在 全 单行 的 情况 下 ， 系 统合 计 耗 时 500 个 时 间 单 位 。 
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图 1.9 串 行 工作 流程 


各 将 步骤 2 和 步骤 5 并 行 化 ， 假 设 在 双核 处 理 上 ， 则 有 如 图 1.10 所 示 
的 处 理 流 程 。 在 这 种 情况 下 ， 步 骤 2 和 步骤 5 的 耗 时 将 为 50 个 时 间 单 位 。 
故 系统 整体 耗 时 为 400 个 时 间 单 位 。 根 据 加 速 比 的 定义 有 : 


加 速 比 = 优化 前 系统 耗 时 /优化 后 系统 耗 时 = 500 / 400 = 1.25 





图 1. 10 双核 处 理 上 的 并 行 化 


或 者 根据 前 文中 给 出 的 加 速 比 公式 。 由 于 5 个 步骤 中 ，3 个 步骤 必须 
串 行 ， 因 此 其 串 行 化 比重 为 345=0.6， 即 F=0.6， 且 双核 处 理 器 的 处 理 器 
个 数 N 为 2。 代 入 公式 得 : 


加 速 比 =1/(0.6+(1-0.6)/2)=1.25 


在 极端 情况 下 ， 假 设 并 行 处 理 器 个 数 为 无 穷 大 ， 则 有 如 图 1.11 所 示 
的 处 理 过 程 。 步 又 2 和 步骤 5 的 处 理 时 间 趋 于 0。 即 使 这 样 ， 系 统 整体 耗 
时 依然 大 于 300 个 时 间 单 位 。 即 加 速 比 的 极限 为 500/300=1.67。 
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图 1.11 极端 情况 下 的 并 行 化 


使 用 加 速 比 计算 公式 ，N 趋 于 无 穷 大 ， 有 加 速 比 =IFE， 且 F=0.6， 故 
有 加 速 比 =1.67。 


由 此 可 见 ， 为 了 提高 系统 的 速度 ， 仅 增加 CPU 处 理 器 的 数量 并 不 一 
定 能 起 到 有 效 的 作用 。 需 要 从 根本 上 修改 程序 的 串 行 行为 ， 提 高 系统 内 
可 并 行 化 的 模块 比重 ， 在 此 基础 上 ， 合 理 增加 并 行 处 理 器 数量 ， 才 能 以 
最 小 的 投入 ， 得 到 最 大 的 加 速 比 。 





YER: 根据 Amdah1 定 律 ， 使 用 多 核 CPU 对 系统 进行 优化 ， 优 化 的 效 
果 取 决 于 CPU 的 数量 以 及 系统 中 的 串 行 化 程序 的 比重 。CPU 数 量 越 

多 ， 串 行 化 比重 越 低 ， 则 优化 效果 越 好 。 仅 提高 CPU 数量 而 不 降低 
程序 的 串 行 化 比重 ， 也 无 法 提高 系统 性 能 。 


1.4.2 Gustafson‘ 42 


Gustafson 定 律 也 试图 说 明 处 理 器 个 数 、 串 行 比例 和 加 速 比 之 则 的 关 
系 ， 如 图 1.12 所 示 ， 但 是 Gustafson 定 律 和 Amdahl 定 律 的 角度 不 同 。 同 
样 ， 加 速 比 都 定义 为 优化 前 的 系统 耗 时 除 以 优化 后 的 系统 耗 时 。 
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图 1. 12 Gustafson 定 律 的 推导 


可 以 看 到 ， 由 于 切入 角度 的 不 同 ，Gustafson 定 律 的 公式 和 Amdahl 
定律 的 公式 截然 不 同 。 从 Gustafson 定 律 中 ， 我 们 可 以 更 容易 地 发 现 ， 如 
条 串 行 化 比例 很 小 ， 并 行 化 比例 很 大 ， 那 么 加 速 比 融 是 处 理 器 的 个 数 。 
只 要 你 不 断 地 累加 处 理 器 ， 束 能 获得 更 快 的 速度 。 


1.4.3 Amdahl 定 律 和 Gustafson 和 定律 
ETHET JS 


由 于 Amdahl 定 律 和 Gustafson 定 律 的 结论 不 同 ， 这 是 不 是 说 明 这 两 
个 理论 之 间 有 一 个 是 错误 的 呢 ? 其 实 不 然 ， 两 者 的 差异 其 实 是 因为 这 两 
个 定律 对 同一 个 客观 事实 从 不 同 角度 去 审视 后 的 结果 ， 它 们 的 偏重 点 有 





所 不 同 。 


举 一 个 生活 的 例子 ， 一 辆 汽车 行驶 在 相聚 60 公 里 的 城市 。 你 花 了 一 
个 小 时 ， 行 驶 了 30 公 里 。 无 论 接 下 来 开 多 快 ， 你 都 不 可 能 达到 90 公 里 / 
小 时 的 时 速 。 图 1.13 很 好 地 说 明了 原因 。 
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图 1. 13 Amdah1 定 律 的 偏重 点 


求解 图 1.13 中 的 方程 ， 你 会 发 现 如 果 你 想 达 到 90 公 里 的 时 速 ， 那 么 
你 从 AB 中 点 到 达 B 点 的 时 间 会 是 一 个 负数 ， 这 显然 不 是 一 个 合理 的 结 
论 。 实 际 上 ， 如 条 前 半 程 30km 你 使 用 了 一 小 时 ， 那 么 即使 你 从 中 点 到 B 
点 使 用 光速 ， 也 只 能 把 整体 的 平均 时 速 维持 在 60km/hour。 


也 就 是 说 Amdahl 强 调 : 当 串 行 比 例 一 定时 ， 加 速 比 是 有 上 限 的 ， 
不 管 你 堆 全 多 少 个 CPU 参 与 计算 ， 都 不 能 突破 这 个 上 限 ! 





而 Gustafson 定 律 的 出 发 点 与 之 不 同 ， 对 Gustafson 定 律 来 说 ， 不 管 你 
从 A 点 出 发 的 速度 有 多 慢 ， 只 要 给 你 足够 的 时 间 和 距离 ， 只 要 你 后 期 的 
速度 比 期 望 值 快 那么 一 点 点 ， 你 总 是 可 以 把 平均 速度 调整 到 非常 接近 那 
个 期 望 值 的 。 比 如 ， 你 想 要 达到 均 速 90km/hour， 即 使 在 前 30km 你 的 时 
速 只 有 30km/hour， 你 只 要 在 很 后 面 的 速度 达到 91km/hour， 给 你 足够 的 
时 间 和 距离 ， 你 总 有 一 天 可 以 把 均 速 提高 到 90km/hour。 














因此 ，Gustafson 定 律 关心 的 是 : 如 果 可 被 并 行 化 的 代码 所 占 比重 中 


够 多 ， 那 么 加 速 比 束 能 随 着 CPU 的 数量 线性 增长 。 


所 以 ， 这 两 个 定律 并 不 矛盾 。 从 极端 角度 来 说 ， 如 果 系 统 中 没有 可 
被 串 行 化 的 代码 ( 即 F=1〉， 那 么 对 于 这 两 个 定律 ， 其 加 速 比 都 是 1。 反 
之 ， 如 果 系 统 中 可 串 行 化 代码 比重 达到 100%， 那 么 这 两 个 定律 得 到 加 
速 比 都 是 n CAFE SBD) o 





1.5 回 到 Java: JMM 


前 面 我 已 经 介绍 了 有 关 并 行程 序 的 一 些 关 键 概念 和 定律 。 这 些 概念 
可 以 说 是 与 语言 无 关 的 。 无 论 你 使 用 Java 或 者 C， 或 者 其 他 任何 一 门 语 
言 编写 并 发 程序 ， 都 有 可 能 会 涉及 这 些 问题 。 但 本 书 依然 是 一 本 面 问 
Java 程 序 员 的 书籍 。 因 此 ， 在 本 章 最 后 ， 我 们 还 是 希望 可 以 探讨 一 下 有 
关 Java 的 内 存 模 型 (JMM) 。 























由 于 并 发 程序 要 比 溃 行程 序 复 杂 很 多 ， 其 中 一 个 重要 原因 是 并 发 程 
序 下 数据 访问 的 一 致 性 和 安全 性 将 会 受到 严重 挑战 。 如 何 保 证 一 个 线程 
可 以 看 到 正确 的 数据 呢 ? 这 个 问题 看 起 来 很 白痴 。 对 于 串 行程 序 来 说 ， 
根本 就 是 小 琳 一 碟 ， 如 果 你 读 取 一 个 变量 ， 这 个 变量 的 值 是 1， 那 么 你 
读 到 的 一 定 是 1， 就 这 么 简单 的 问题 在 并 行程 序 中 居然 变 得 复杂 起 来 。 
事实 上 ， 如 果 不 加 控制 地 任 由 线程 胡乱 并 行 ， 即 使 原本 是 1 的 数值 ， 你 
也 有 可 能 读 到 2。 因 此 ， 我 们 需要 在 深入 了 解 并 行 机 制 的 前 提 下 ， 再 定 
义 一 种 规则 ， 保 证 多 个 线程 间 可 以 有 效 地 、 正 确 地 协同 工作 。 而 JMM 也 
就 是 为 此 而 生 的 。 














JMM 的 关键 技术 点 都 是 围绕 着 多 线程 的 原子 性 、 可 见 性 和 有 序 性 来 
建立 的 。 因 此 ， 我 们 首先 必须 了 解 这 些 概念 。 


1.5.1 原子 性 (Atomicity) 





原子 性 是 指 一 个 操作 是 不 可 中 断 的 。 即 使 是 在 多 个 线程 一 起 执行 的 
时 候 ， 一 个 操作 一 旦 开始 ， 残 不 会 被 其 他 线程 干扰 。 


比如 ， 对 于 一 个 静态 全 局 变量 int i， 两 个 线程 同时 对 它 赋值 ， 线 程 
A 给 他 赋值 1， 线 程 B 给 它 赋值 为 -1。 那 么 不 管 这 2 个 线程 以 何 种 方式 、 
何 种 步调 工作 ，i 的 值 要 么 是 1， 要 么 是 -1。 线 程 A 和 线程 B 之 间 是 没有 干 
扰 的 。 这 就 是 原子 性 的 一 个 特点 ， 不 可 被 中 断 。 











但 如 果 我 们 不 使 用 int 型 而 使 用 long 型 的 话 ， 可 能 就 没有 那么 幸运 
了 。 对 于 32 位 系统 来 说 ，long 型 数据 的 读 写 不 是 原子 性 的 (因为 long 有 
64 位 ) 。 也 就 是 说 ， 如 果 两 个 线程 同时 对 long 进 行 写 入 的 话 〈 或 者 读 
取 ) ， 对 线程 之 间 的 结果 是 有 干扰 的 。 





大 家 可 以 仔细 观察 一 下 下 面 的 代码 : 


public class MultiThreadLong { 
public static long t=0; 
public static class ChangeT implements Runnable{ 
private long to; 
public ChangeT(long to){ 
this.to=to; 
i 
@Override 
public void run() { 
while(true){ 
MultiThreadLong.t=to; 
Thread.yield(); 
t 


i 


public static class ReadT implements Runnable{ 


@Override 
public void run() { 
while(true) { 
long tmp=MultiThreadLong.t; 
if(tmp!=111L && tmp!=-999L && tmp!=333L && tmp!=-444 
System.out.printin(tmp); 
Thread. yield(); 
} 


public static void main(String[] args) { 
new Thread(new ChangeT(111L)).start(); 
new Thread(new ChangeT(-999L)).start(); 
new Thread(new ChangeT(333L)).start(); 
new Thread(new ChangeT(-444L)).start(); 


new Thread(new ReadT()).start(); 


上 述 代 码 有 4 个 线程 对 long 型 数据 t 进 行 赋值 ， 分 别 对 {t 赋 值 为 
111、-999、333、444。 然 后 ， 有 一 个 读 取 线 程 ， 读 取 这 个 t 的 值 。 一 般 
来 说 ，t 的 值 总 是 这 4 个 数值 中 的 一 个 。 这 当然 也 是 我 们 的 期 望 了 。 但 很 
不 季 ， 在 32 位 的 Java 虚 拟 机 中 ， 未 必 总 是 这 样 。 





如 果 读 取 线 程 ReadT 总 是 读 到 合理 的 数据 ， 那 么 这 个 程序 应 该 没有 
任何 输出 。 但 是 ， 实 际 上 ， 这 个 程序 一 旦 运行 ， 束 会 大 量 输出 以 下 信 


BB: 《和 再 次 强调 ， 使 用 32 位 虚拟 机 ) 


-4294966963 
4294966852 
-4294966963 


这 里 截取 了 部 分 输出 。 我 们 可 以 看 到 ， 读 取 线 程 大 然 读 到 了 两 个 似 
平 根本 不 可 能 存在 的 数值 。 这 不 是 幻觉 ， 在 这 里 ， 你 看 到 的 确实 是 事 
实 ， 其 中 的 原因 也 就 是 因为 32 位 系统 中 long 型 数据 的 读 和 写 都 不 是 原子 
性 的 ， 多 线程 之 间 相 互 干扰 了 ! 

















如 果 我 给 出 这 几 个 数值 的 2 进 制 表 示 ， 大 家 就 会 有 更 清晰 的 认识 
J: 


+111=000000000000000000000000000000000000000000000000000000000110 
-999=111111111111111111111111111111111111111111111111111111000001 
+333=000000000000000000000000000000000000000000000000000000010100 
-444=111111111111111111111111111111111111111111111111111111100100 
+4294966852=00000000000000000000000000000000111111111111111111111 
-4294967185=11111111111111111111111111111111000000000000000000000 





上 面 显 示 了 这 几 个 相关 数字 的 补 码 形式 ， 也 就 是 在 计算 机 内 的 真实 
存储 内 容 。 不 难 发 现 ， 这 个 奇怪 的 4294966852， 其 实 是 111 或 者 333 的 前 
32 位 ， 与 -444 的 后 32 位 夹杂 后 的 数字 。 而 -4294967185 只 是 -999 或 者 -444 
的 前 32 位 与 111 夹 杂 后 的 数字 。 换 句 话说 ， 由 于 并 行 的 关系 ， 数 字 被 写 
乱 了 ， 或 者 读 的 时 候 ， 读 串 位 了 。 





通过 这 个 例子 ， 我 想 大 家 都 原子 性 应 该 有 了 基本 的 认识 。 
1.5.2 ”可见 性 (Visibility ) 


可 见 性 是 指 当 一 个 线程 修改 了 茶 一 个 共 孚 变量 的 值 ， 其 他 线程 是 个 
能 够 立即 知道 这 个 修改 。 显 然 ， 对 于 串 行 程序 来 说 ， 可 见 性 问题 是 不 存 
在 的 。 因 为 你 在 任何 一 个 操作 步骤 中 修改 了 东 个 变量 ， 那 么 在 后 续 的 步 
又 中 ， 读 取 这 个 变量 的 值 ， 一 定 是 修改 后 的 新 值 。 











但 是 这 个 问题 在 并 行程 序 中 就 不 见得 了 。 如 果 一 个 线程 修改 了 某 一 
个 全 局 变量 ， 那 么 其 他 线程 未 必 可 以 马上 知道 这 个 改动 。 图 1.14 展 示 了 
发 生 可 见 性 问题 的 一 种 可 能 。 如 果 在 CPU1 和 CPU2 上 各 运行 了 一 个 线 
程 ， 它 们 共享 变量 t， 由 于 编译 器 优化 或 者 硬件 优化 的 缘故 ， 在 CPU1 上 
的 线程 将 变量 t 进 行 了 优化 ， 将 其 缓存 在 cache 中 或 者 寄存 器 里 。 这 种 情 
况 下 ， 如 果 在 CPU2 上 的 某 个 线程 修改 了 变量 t 的 实际 值 ， 那 么 CPU1 上 的 
线程 可 能 并 无 法 意识 到 这 个 改动 ， 依 然 会 读 取 cache 中 或 者 寄存 器 里 的 
数据 。 因 此 ， 就 产生 了 可 见 性 问题 。 外 在 表现 为 : 变量 t 的 值 被 修改 ， 
但 是 CPU1 上 的 线程 依然 会 读 到 一 个 旧 值 。 可 见 性 问题 也 是 并 行程 序 开 
发 中 需要 重点 关注 的 问题 之 一 。 
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图 1.14 可 见 性 问题 





可 见 性 问题 是 一 个 综合 性 问题 。 除 了 上 述 提 到 的 缓存 优化 或 者 硬件 
优化 《有 些 内 存 读 写 可 能 不 会 立即 触发 ， 而 会 先进 入 一 个 硬件 队列 等 
FO 会 导致 可 见 性 问题 外 ， 指 令 重 排 (这 个 问题 将 在 下 一 市 中 更 详细 讨 
W) 以 及 编辑 器 的 优化 ， 都 有 可 能 导致 一 个 线程 的 修改 不 会 立即 被 其 他 





下 面 来 看 一 个 简单 的 例子 : 


Thread 1 Thread 2 
ee elie ree ene I ERB; 


24 Be aie 4: A= 2; 


上 述 两 个 线程 ， 并 行 执行 ， 分 别 有 1、2、3、4 四 条 指令 。 其 中 指令 
1、2 属 于 线程 1， 而 指令 3、4 属 于 线程 2。 





从 指令 的 执行 顺序 上 看 ，r2==2 并 且 r1==1 似 乎 是 不 可 能 出 现 的 。 但 
实际 上 ， 我 们 并 没有 办 法 从 理论 上 保证 这 种 情况 不 出 现 。 因 为 编译 器 可 
能 将 指令 重 排 成 : 





Thread 1 Thread 2 
Bea ear fl = 


r2 = A; A= 2; 





在 这 种 执行 顺序 中 ， 就 有 可 能 出 现 刚才 看 似 不 可 能 出 现 的 r2==2 并 
且 r1==1 的 情况 了 。 


这 个 例子 就 说 明 ， 在 一 个 线程 中 去 观察 另外 一 个 线程 的 变量 ， 它 们 
HE 


的 值 是 否 能 观测 到 、 何 时 能 观测 到 是 没有 保证 的 。 











再 来 看 一 个 稍微 复杂 一 些 的 例子 : 


Thread 1 Thread 2 
= r6 = p; 

F2 = rl X? rex = 3; 
r3 = q; 


r4 = r3.x; 


rS ED 


这 里 假设 在 初始 时 ，p == q 并 且 p.x == 0。 对 于 大 部 分 编译 器 来 说 ， 
可 能 会 对 线程 1 进行 向 前 蔡 换 的 优化 ， 也 就 是 r5=rl.x 这 条 指令 会 被 直接 
蔡 换 成 r5=r2。 因 为 它们 都 读 取 了 rl.x， 又 发 生 在 同一 个 线程 中 ， 因 此 ， 
编译 器 很 可 能 认为 第 2 次 读 取 是 完全 没有 必要 的 。 因 此 ， 上 述 指令 可 能 
RER: 





Thread 1 Thread 2 
ri = p; r6 = p; 
r2 = r1.x; 63% = 3, 


r3 = q; 


r4 = r3.x; 


r5 = r2; 


现在 思考 这 么 一 种 场景 。 假 设 线程 2 中 的 r6.x=3 发 生 在 r2 = r1.xMr4 
= r3.x 之 间 ， 而 编译 器 又 打算 重用 r2 来 表示 r5。 那 么 就 有 可 能 会 出 现 非 第 
奇怪 的 现象 。 你 看 到 的 2 是 0，r4 是 3， 但 是 r5 还 是 0。 因 此 ， 如 果 从 线程 
1 代码 的 直观 感 党 上 看 就 是 : p.x 的 值 从 0 变 成 了 3 因为 r4 是 3) ， 接 着 义 
变 成 了 0〔 这 是 不 是 算 一 个 非常 怪 腊 的 问题 昵 ?) 。 














15.3 AJFIE (Ordering) 





有 序 性 问题 可 能 是 三 个 问题 中 最 难 理解 的 了 。 对 于 一 个 线程 的 执行 
代码 而 言 ， 我 们 总 是 习惯 地 认为 代码 的 执行 是 从 先 往 后 ， 依 次 执行 的 。 
这 么 理解 也 不 能 说 完全 错误 ， 因 为 就 一 个 线程 内 而 言 ， 确 实 会 表现 成 这 
样 。 但 是 ， 在 并 发 时 ， 程 序 的 执行 可 能 整 会 出 现 乱 序 。 给 入 直观 的 感觉 
就 是 : 写 在 前 面 的 代码 ， 会 在 后 面 执行 。 听 起 来 有 些 不 可 思议 ， 是 吗 ? 
有 序 性 问题 的 原因 是 因为 程序 在 执行 时 ， 可 能 会 进行 指令 重 排 ， 重 排 后 
的 指令 与 原 指 令 的 顺序 未 必 一 致 。 下 面 来 看 一 个 简单 的 例子 : 








01 class OrderExample { 
02 int a = 0; 
03 boolean flag = false; 


94 public void writer() { 


05 a=1,; 
06 flag = true; 
07 } 


08 public void reader() { 


09 if (flag) { 


10 int i= a +1; 


假设 线程 A 首 先 执行 writer0) 方 法 ， 接 着 线程 B 执 行 reader0 方 法 ， 如 
果 发 生 指 令 重 排 ， 那 么 线程 B 在 代码 第 10 行 时 ， 不 一 定 能 看 到 a 已 经 被 赋 
值 为 1 了 。 如 图 1.15 所 示 ， 显 示 了 两 个 线程 的 调用 关系 。 
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图 1. 15 “指令 重 排 引起 线程 间 语 义 不 一 臻 
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这 确实 是 一 个 看 起 来 很 奇怪 的 问题 ， 但 是 它 确 实 可 能 存在 。 注 意 : 
我 这 里 说 的 是 可 能 存在 。 因 为 如 果 指 令 没有 重 排 ， 这 个 问题 束 不 存在 
T, (Bete eR RE RHE WWEH, RM eR MCAT. A 
此 ， 对 于 这 类 问题 ， 我 认为 比较 严谨 的 描述 是 : 线程 A 的 指令 执行 顺序 
在 线程 B 看 来 是 没有 保证 的 。 如 果 运 气 好 的 话 ， 线 程 B 也 许 真 的 可 以 看 
到 和 线程 A 一 样 的 执行 顺序 。 








不 过 这 里 还 需要 强调 一 氮 ， 对 于 一 个 线程 来 说 ， 它 看 到 的 指令 执行 
顺序 一 定 是 一 致 的 《人 否则 的 话 我 们 的 应 用 根本 无 法 正常 工作 ， 不 是 
吗 ? ) 。 也 就 是 说 指令 重 排 是 有 一 个 基本 前 提 的 ， 就 是 保证 串 行 语义 的 
一 致 性 。 指 令 重 排 不 会 使 串 行 的 语义 逻辑 发 生 问 题 。 因 此 ， 在 串 行 代码 
中 ， 大 可 不 必 担 心 。 





注意 : 指令 重 排 可 以 保证 串 行 语义 一 致 ， 但 是 没有 义务 保证 多 线程 
间 的 语义 也 一 致 。 





那么 ， 好 奇 的 你 可 能 号 上 就 会 在 脑海 里 内 出 一 个 疑问 ， 为 什么 要 指 
QEA? 让 他 一 步 一 步 执行 多 好 呀 ! 也 不 会 有 那么 多 奇 酝 的 问题 。 





之 所 以 那么 做 ， 完 全 是 因为 性 能 考虑 。 我 们 知道 ， 一 条 指令 的 执行 
是 可 以 分 为 很 多 步 又 的 。 简 单 地 说 ， 可 以 分 为 以 下 儿 步 : 


e 取 指 IF 

译 码 和 取 寄 存 器 操作 数 ID 
执行 或 者 有 效 地 址 计算 EX 
存储 器 访问 MEM 

。 写 回 WB 


我 们 的 汇编 指令 也 不 是 一 步 就 可 以 执行 完毕 的 ， 在 CPU 中 实际 工作 
时 ， 它 还 是 需要 分 为 多 个 步 又 依次 执行 的 。 当 然 ， 每 个 步骤 所 涉及 的 硬 
件 也 可 能 不 同 。 比 如 ， 取 指 时 会 用 到 PC 寄存 器 和 存储 器 ， 译 码 时 会 用 
到 指令 寄存 器 组 ， 执 行 时 会 使 用 ALU， 写 回 时 需要 寄存 器 组 。 








JER: ALU 指 算术 逻辑 单元 。 它 是 CPU 的 执行 单元 ， 是 CPU 的 核心 组 
成 部 分 ， 主 要 功能 是 进行 二 进 制 算 术 运 算 。 


由 于 每 一 个 步骤 都 可 能 使 用 不 同 的 硬件 完成 ， 因 此 ， 聪 明 的 工程 师 
们 就 发 明了 流水 线 技术 来 执行 指令 ， 如 图 1.16 所 示 ， 显 示 了 流水 线 的 工 
作 原 理 。 


4e | H | D 上 人 | VIE /| W D 
i 7D LY mem we 
his 2 E- | L [4 | YA." /| aa, | VI D 


图 1. 16 ”指令 流水 线 


可 以 看 到 ， 当 人 第 2 条 指令 执行 时 ， 第 1 条 执行 其 实 并 未 执行 完 ， 确 切 
地 说 第 一 条 指令 还 没 开 始 执行 ， 只 是 刚刚 完成 了 取 值 操作 而 已 。 这 样 的 
好 处 非常 明显 ， 假 如 这 里 每 一 个 步骤 都 需要 人 花费 1 坚 秒 ， 那 么 指令 2 等 符 
引信 1 完全 执行 后 ， 再 执行 ， 则 需要 等 待 5 坚 秒 ， 而 使 用 流水 线 后 ， 指 令 
2 只 需要 等 待 1 坚 秒 就 可 以 执行 了 。 如 此 大 的 性 能 提升 ， 当 然 让 人 眼红 。 
更 何况 ， 实 际 的 商业 CPU 的 流水 线 级 别 甚至 可 以 达到 10 级 以 上 ， 则 性 能 
提升 就 更 加 明显 。 














有 了 流水 线 这 个 神器 ， 我 们 CPU 才 能 真正 局 效 的 执行 ， 但 是 ， 别 忘 
了 一 点 ， 流 水 线 总 是 害怕 被 中 断 的 。 流 水 线 满载 时 ， 性 能 确实 相当 不 
错 ， 但 是 一 旦 中 断 ， 所 有 的 人 硬件 设备 部 会 进入 一 个 停顿 期 ， 再 次 满载 义 
需要 几 个 周期 ， 因 此 ， 人 性 能 损失 会 比较 大 。 所 以 ， 我 们 必须 要 想 办 法 尽 
量 不 证 流水 线 中 断 ! 





那么 答案 束 来 了 ， 之 所 以 需要 做 指令 重 排 ， 束 是 为 了 尽量 少 的 中 断 
流水 线 。 当 然 了 ， 指 令 重 排 只 是 减少 中 断 的 一 种 技术 ， 实 际 上 ， 在 CPU 
的 设计 中 ， 我 们 还 会 使 用 更 多 的 软 硬 件 技术 来 防止 中 断 ， 不 过 对 它们 的 
讨论 已 经 远 远 超 出 本 书 范围 ， 有 兴趣 的 读者 可 以 查阅 相关 资料 。 


让 我 们 来 仔细 看 一 个 例子 。 图 1.17 展 示 了 A=B+C 这 个 操作 的 执行 过 
程 。 写 在 左边 的 指令 就 是 汇编 指令 。LW 表 示 load， 其 中 LW R1,B， 表 示 
把 B 的 值 加 载 到 R1 寄 存 器 中 。ADD 指 令 就 是 加 法 ， 把 R1、R2 的 值 相 
加 ， 并 存放 到 R3 中 。SW 表 示 store， 存 储 ， 就 是 将 R3 寄 存 器 的 值 保存 到 


A = B f E 94 x 
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图 1. 17 A=B+C 的 执行 过 程 


右边 就 是 流水 线 的 情况 。 注 意 ， 在 ADD 指 令 上 ， 有 一 个 大 又 ， 表 示 
一 个 中 断 。 也 束 是 说 ADD 在 这 里 停顿 了 一 下 。 为 什么 ADD 会 在 这 里 停 
顿 呢 ? 原因 很 简单 ，R2 中 的 数据 还 没有 准备 好 ! 所 以 ，ADD 操 作 必须 
进行 一 次 等 待 。 由 于 ADD 的 延迟 ， 导 致 其 后 面 所 有 的 指令 都 要 慢 一 个 节 
拍 。 





理解 了 上 面 这 个 例子 ， 我 们 残 可 以 来 看 一 个 更 加 复杂 的 情况 : 


a=b+c 


d=e -f 





上 述 代码 的 执行 应 该 会 是 这 样 ， 如 图 1.18 所 示 。 


LW $b IF ID EX MEM WB 
IF ID EX mem wo 


LW Rec 

ADD ba, Rb. Re r TO x EX Mm Wh 

SW Ak, ir xX we Mam WwW 

LW kee X IF ID EX MEM WB 

LW bf $ IE Ww EX MM wọ 

sud RA Re RF m ID x EX Mem WB 

SW A Rok IF x ID EX Mem We 


图 1.18 重 排 前 指令 执行 过 程 


由 于 ADD 和 SUB 都 需要 等 待 上 一 条 指令 的 结果 ， 因 此 ， 在 这 里 插入 
了 不 少 停顿 。 那 么 对 于 这 段 代 码 ， 是 否 有 可 能 消除 这 些 停顿 呢 ? 显然 是 
可 以 的 ， 如 图 1.19 所 示 ， 显 示 了 减少 这 些 停顿 的 方法 。 我 们 只 需要 将 
LW Re, e 和 LW Rf, f 移 动 到 前 面 执 行 即 可 。 思 想 很 简单 ， 先 加 载 e 和 f 对 
程序 是 没有 影响 的 。 既 然 在 ADD 的 时 候 一 定 要 停顿 一 下 ， 那 么 停顿 的 时 
间 还 不 如 去 做 点 有 意义 的 事情 。 

















LW 2b, b IF ID EX MEM WB 


LW Roc IE ID EK MEM WB 
E 
ADD Pa, Rb. Re r TD x EX Mem WB 
SW Aka IF x -ID EX MEM WB 
AW Rese F X IF ID EX MEM WB 
LW $f - IF ID EX MeM wọ 
Sud hA Re Rf r ID x EX Mim WB 
SW dM IF x DEX MM W 


图 1. 19 ”指令 重 排 ， 以 消除 停顿 


重 排 后 ， 最 终 的 结果 如 图 1.20 所 示 。 可 以 看 到 ， 所 有 的 停顿 都 已 经 
消除 ， 流 水 线 已 经 可 以 十 分 顺畅 地 执行 。 


LW 妙 p IF ID EX MEM WB 


LW Red Ir ID EX MM we 
LW kee IF ID EX MEM WB 

ADD ba, R>. Re rp LD EX Men WB 

LW 好 二 IF ID id MEM WÈ 

SW AR, IF ID EX MH Wb 

Sud BA Re AF r ID EX Mem WB 

SW ARA IF mw EX Mem W 


图 1. 20” 重 排 后 的 指令 


由 此 可 见 ， 指 令 重 排 对 于 提高 CPU 处 理性 能 是 十 分 必要 的 。 虽 然 确 
实 带 来 了 乱 序 的 问题 ， 但 是 这 点 牺牲 是 完全 值得 的 。 


1.5.4 哪些 指令 不 能 重 排 : Happen- 
Before 规 则 


在 前 文 已 经 介绍 了 指令 重 排 ,虽然 Java 虚 拟 机 和 执行 系统 会 对 指令 
进行 一 定 的 重 排 但 是 指令 重 排 是 有 原则 的 ， 并 非 所 有 的 指令 部 可 以 随 
便 改变 执行 位 置 ， 以 下 罗列 了 一 些 基 本 原则 ， 这 些 原则 是 指令 重 排 不 可 
违背 的 。 





。 程序 顺序 原则 : 一 个 线程 内 保证 语义 的 串 行 性 

。 volatile 规 则 : volatile 变 量 的 写 ， 先 发 生 于 恋 ， 这 保证 了 volatile 变 
量 的 可 见 性 

o 锁 规 则 : 解锁 Cunlock) 必然 发 生 在 随后 的 加 锁 Clock) 前 

。 传递 性 : A 先 于 B，B 先 于 C， 那 么 A 必 然 先 于 C 


线程 的 start(0) 方 法 先 于 它 的 每 一 个 动作 

线程 的 所 有 操作 先 于 线程 的 终结 (Thread.join()) 
o 线程 的 中 断 Cinterrupt()) 先 于 被 中 断 线程 的 代码 
。 对 象 的 构造 函数 执行 、 结 束 先 于 finalize() 方 法 


以 程序 顺序 原则 为 例 ， 重 排 后 的 指令 绝对 不 能 改变 原 有 的 串 行 语 
Mo Ebi: 


a=1; 


b=a+1; 


由 于 第 2 条 语句 依赖 第 一 条 的 执行 结果 。 如 果 冒 然 交 换 两 条 语句 的 
执行 顺序 ， 那 么 程序 的 语义 整 会 修改 。 因 此 这 种 情况 是 绝对 不 允许 发 生 
的 。 因 此 ， 这 也 是 指令 重 排 的 一 条 基本 原则 。 


此 外 ， 锁 规则 强调 ，unlock 操 作 必然 发 生 在 后 续 的 对 同一 个 锁 的 
lock 之 前 。 也 就 是 说 ， 如 果 对 一 个 锁 解 锁 后 ， 再 加 锁 ， 那 么 加 锁 的 动作 
绝对 不 能 重 排 到 解锁 动作 之 前 。 很 显然 ， 如 果 这 么 做 ， 加 锁 行 为 是 无 法 
获得 这 把 锁 的 。 








其 他 几 条 原则 也 是 类 似 的 ， 这 些 原 则 都 是 为 了 保证 指令 重 排 不 会 破 
坏 原 有 的 语义 结构 。 
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第 2 章 ”Java 并 行程 友基 础 


我 们 已 经 探讨 为 什么 必须 面 对 并 行程 序 这 样 复杂 的 程序 设计 方法 ， 
那么 下 面 束 需要 静 下 心 来 ， 认 真 研究 如 何 才能 构建 一 个 正确 、 健 壮 并 且 
高 效 的 并 行 系统 。 本 章 将 详细 介绍 有 关 Java 并 行程 序 的 设计 基础 ， 以 及 
一 些 常 见 的 问题 ， 希 望 对 读者 有 所 帮助 。 





21 有 天 线程 你 必须 知道 的 事 


在 介绍 线程 前 ， 我 们 还 是 先 了 解 一 下 线程 的 “ 母 杀 ”一 一 进程 。 如 果 
你 有 读 过 操作 系统 的 谍 程 ， 那 你 对 进程 一 定 不 会 陌生 。 在 这 种 专业 级 的 
书籍 中 ， 应 该 会 给 出 一 些 “ 官 方 ” 的 解释 ， 比 如 像 下 面 这 样 描述 : 














HEFE (Process) 是 计算 机 中 的 程序 关于 某 数 据 集合 上 的 一 次 运行 活 
动 ， 是 系统 进行 资源 分 配 和 调度 的 基本 单位 ， 是 操作 系统 结构 的 基础 。 
在 早期 面 加 进程 设计 的 计算 机 结构 中 ， 进 程 是 程序 的 基本 执行 实体 ， 在 
当代 面 同 线程 设 计 的 计算 机 结构 中 ， 进 程 是 线程 的 容器 。 程 序 是 指令 、 
数据 及 其 组 织 形式 的 描述 ， 进 程 是 程序 的 实体 。 








不 过 我 不 想 把 这 种 严谨 上 且 抽 象 的 描述 介绍 给 大 家 。 用 一 句 简单 的 话 
来 说 ， 你 在 windows 中 ， 看 到 的 后 级 为 .exe 的 文件 ， 都 是 一 个 程序 。 不 
过 程序 是 死 的 ， 静 态 的 。 当 你 双击 这 个 .exe 执 行 的 时 候 ， 这 个 .exe 文 件 
中 的 指令 就 会 被 加 载 ， 那 么 你 就 能 得 到 一 个 有 关 这 个 .exe 程 序 的 一 个 进 
程 。 进 程 是 “ 活 ” 的 ， 或 者 说 是 正在 被 执行 的 。 图 2.1 使 用 任务 管理 器 ， 显 
示 了 当前 系统 中 的 进程 。 














图 2.1 系统 进程 信息 


进程 中 可 以 容纳 若干 个 线程 。 它 们 并 不 是 看 不 见 、 摸 不 着 的 ， 也 可 
以 使 用 工具 看 到 它们 ， 如 图 2.2 所 示 。 


oe ee 
Image Performance | Performance Graph | DiskandNetwork 
Threads | Tcpfip | Security | Environment | strings | 


-。 Start Address 





























MSVCR100. di1!_endthreadex+0x80 
MSVCRi00. dil!_endthreadex+0x80 
MSVCRi00. dil!_endthreadex+0x80 
MSVCR100. dil!_endthreadex+0x80 
MSVCR100. di1!_endthreadex+0x80 
MSVCRi00. dil!_endthreadex+0x80 


MSVCR100. dil!_endthreadex+0x80 

MSVCR100. di1!_endthreadex+0x80 

MSVCR100. dil!_endthreadex+0x80 
AMID nwa. 


cures An tee nn ane ON 

















Thread ID: 5184 

Start Time: 20:44:04 2015-2-28 

State: Wait:WrUserRequest Base Priority: 

Kernel Time: 0:00:05.850 Dynamic Priority: 
User Time: 0:00: 14.991 I/O Priority: 

Context Switches: 287,235 Memory Priority: 
Cydes: 75, 167,745,569 Ideal Processor: 0 


Permissions Kill Suspend 
Lo ] Lee | 
图 2.2 进程 中 线程 的 信息 




















那 线程 和 进程 之 间 究 竟 是 一 种 什么 样 的 关系 呢 ? 简单 地 说 ， 进 程 是 
一 个 容器 。 比 如 一 间 漂 亮 的 小 别墅 。 别 墅 里 有 电视 、 厨 房 、 书 房 、 洗 手 
间 等 。 当 然 ， 还 有 一 家 三 口 住 在 里 面 。 当 妈妈 带 女 儿 外 出 游玩 时 ， 和 区 多 
一 人 在 家 。 这 时 多 多 一 个 人 在 家 里 爱 上 哪里 去 哪里 、 爱 干 电 干咳 ， 这 
时 ， 和 爸 和 爸 就 像 一 个 线程 《这 个 进程 中 只 有 一 个 活动 线程 ) Fil SER 
一 个 进程 ， 家 里 的 电视 、 厨 房 、 书 房 束 像 这 个 进程 占有 的 资源 。 当 到 三 
个 人 住 在 一 起 时 (相当 于 三 个 线程 》， 有 了 时候 可 能 束 会 有 些小 冲突 ， 比 
如 ， 当 女儿 占 着 电视 机 看 动画 片 时 ， 和 爸 和 爸 就 不 能 看 体育 频道 上， 这 就 是 
线程 间 的 资源 竞争 。 当 然 ， 大 部 分 时 候 ， 线 程 之 间 还 是 协作 关系 〈 如 果 
我 们 创建 线程 是 用 来 打架 的 ， 那 创建 它 干 呆 呢 ? ) 。 比 如 ， 妈 妈 在 厨房 
为 爸爸 和 女儿 做 饭 ， 和 爸爸 在 书房 工作 赚钱 养家 糊口 ， 女 儿 在 写作 业 ， 各 





其 职 ， 那 么 这 个 家 就 是 其 乐 融融 了 ， 相 对 的 ， 这 个 进程 也 融 在 健康 地 





用 稍微 专业 后 的 术语 说 ， 线 程 束 是 轻 量 级 进程 ， 是 程序 执行 的 最 小 
单位 。 使 用 多 线程 而 不 是 用 多 进程 去 进行 并 发 程序 的 设计 ， 是 因为 线程 
闻 的 切换 和 调度 的 成 本 远 远 小 于 进程 。 





接 下 来 让 我 们 更 细致 地 观察 一 个 线程 的 生命 周期 。 我 们 可 以 绘制 一 
张 简单 的 状态 图 来 描述 这 个 概念 ， 如 图 2.3 所 示 。 
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图 2.3 ”线程 状态 图 


线程 的 所 有 状态 都 在 Thread 中 的 State 枚 举 中 定义 ， 如 下 所 示 : 


public enum State { 
NEw, 
RUNNABLE, 
BLOCKED, 
WAITING, 
TIMED_WAITING, 
TERMINATED; 


NEW 状 态 表示 刚刚 创建 的 线程 ， 这 种 线程 还 没 开 始 执行 。 等 到 线 
程 的 start() 方 法 调用 时 ， 才 表示 线程 开始 执行 。 当 线程 执行 时 ， 处 于 
RUNNABLE 状 态 ， 表 示 线 程 所 需 的 一 切 资源 都 已 经 准备 好 了 。 如 果 线 
程 在 执行 过 程 中 遇 到 了 synchronized 同 步 块 ， 束 会 进入 BLOCKED 阻 塞 状 
态 ， 这 时 线程 就 会 暂停 执行 ， 直 到 获得 请 求 的 锁 。WAITING 和 
TIMED_WAITING 都 表示 等 待 状态 ， 它 们 的 区 别 是 WAITING 会 进入 一 
个 无 时 间 限 制 的 等 待 ，TIMED_WAITING 会 进行 一 个 有 时 限 的 等 待 。 那 
等 待 的 线程 究竟 在 等 什么 呢 ? 一 般 来 说 ，WAITING 的 线程 正 是 在 等 待 
一 些 特殊 的 事件 。 比 如 ， 通 过 wait0 方 法 等 待 的 线程 在 等 待 notify() 方 
法 ， 而 通过 join() 方 法 等 待 的 线程 则 会 等 待 目 标 线程 的 终止 。 一 旦 等 到 
了 期 户 的 事件 ， 线 程 就 会 再 次 执行 ， 进 入 RUNNABLE 状 态 。 当 线程 执 
行 完 毕 后 ， 则 进入 TERMINATED 状 态 ， 表 示 结 束 。 

















注意 : 从 NEW 状 态 出 发 后 ， 线 程 不 能 再 回 到 NEW 状 态 ， 同 理 ， 处 于 
TERMINATED 的 线程 也 不 能 再 回 到 RUNNABLE 状 态 。 


2.2 ”初始 线程 :线程 的 基本 操作 


进行 Java 并 发 设计 的 第 一 步 ， 就 是 必须 要 了 解 Java 中 为 线程 操作 所 
提供 的 一 些 API。 比 如 ， 如 何 新 建 并 且 局 动 线程 ， 如 何 终止 线程 、 中 断 
线程 等 。 当 然 了 ， 因 为 并 行 操 作 要 比 串 行 操 作 复 杂 得 多 ， 于 是 ， 围 绕 着 
mee AO, Fy eA HSER SU eae AR. TAS tS 


能 地 将 一 些 潜在 问题 描述 清楚 。 


2.2.1 ”新建 线 程 


新 建 线程 很 简单 。 只 要 使 用 new 关 键 字 创建 一 个 线程 对 象 ， 并 且 将 
它 start0 起 来 即 可 。 














Thread ti=new Thread()j; 


ti.start(); 





那 线程 start0 后 ， 会 干什么 呢 ? 这 才 是 问题 的 关键 。 线 程 Thread， 
有 一 个 run0) 方 法 ，start0) 方 法 就 会 新 建 一 个 线程 并 让 这 个 线程 执行 run0) 
Thins 
这 里 要 注意 ， 下 面 的 代码 也 能 通过 编译 ， 也 能 正常 执行 。 但 是 ， 却 


不 能 新 建 一 个 线程 ， 而 是 在 当前 线程 中 调用 run0) 方 法 ， 只 是 作为 一 个 普 
通 的 方法 调用 。 


Thread ti=new Thread(); 


ti.run(); 


因此 ， 在 这 里 希望 大 家 特别 注意 ， 调 用 start(0) 方 法 和 直接 调用 run0) 
方法 的 区 别 。 


注意 ; 不 要 用 run () 来 开启 新 线程 。 它 只 会 在 当前 线程 中 ， 串 行 执 
行 run (0) 中 的 代码 。 


局 动 就 号 上 结束 了 。 如 果 你 想 让 线程 做 点 什么 ， 就 必须 重 载 run() 方 法 ， 
把 你 的 “任务 ? 盾 进 去 。 





Thread ti=new Thread(){ 
@Override 
public void run(){ 


System.out.printin("Hello, I am t1"); 


}; 
ti.start(); 


上 述 代 码 使 用 匿名 内 部 类 ， 重 载 了 run() 方 法 ， 并 要 求 线程 在 执行 时 
打印 *Helo，I am t1” 的 字样 。 如 果 没 有 特别 的 需要 ， 都 可 以 通过 继承 
Thread， 重 载 run() 方 法 来 自 定 义 线程 。 但 考虑 到 Java 是 单 继 承 的 ， 也 束 
是 说 继承 本 身 也 是 一 种 很 宝贵 的 资源 ， 因 此 ， 我 们 也 可 以 使 用 Runnable 
接口 来 实现 同样 的 操作 。Runnable 接 口 是 一 个 单方 法 接口 ， 它 只 有 一 个 
run0 方 法 : 











public interface Runnable { 


public abstract void run(); 


此 外 ，Thread 类 有 一 个 非常 重要 的 构造 方法 : 


public Thread(Runnable target) 





它 传 入 一 个 Runnable 接 口 的 实例 ， 在 start() 方 法 调用 时 ， 新 的 线程 
就 会 执行 Runnable.run() 方 法 。 实 际 上 ， 默 认 的 Thread.run() 束 是 这 么 做 
的 : 


public void run() { 
if (target != null) { 


target.run(); 


JER: 默认 的 Thread. run () 就 是 直接 调用 内 部 的 Runnable 接 口 。 
此 ， 使 用 Runnable 接 口 告诉 线程 该 做 什么 ， 更 为 合理 。 


public class CreateThread3 implements Runnable { 
public static void main(String[] args) { 
Thread ti=new Thread(new CreateThread3() ); 


ti.start(); 


@Override 
public void run() { 


System.out.printin("Oh, I am Runnable"); 


上 述 代码 实现 了 Runnable 接 口 ， 并 将 该 实例 传 入 Thread。 这 样 避免 
重 载 Thread.run(0)， 单 纯 使 用 接口 来 定义 Thread， 也 是 最 党 用 的 做 法 。 


2.2.2 ”终止 线程 


一 般 来 次 ， 线 程 在 执行 完毕 后 就 会 结束 ， 无 须 手 工 关闭 。 但 是 ， 几 
事 也 都 有 例外 。 一 些 服 务 端 的 后 台 线 程 可 能 会 第 驻 系 统 ， 它 们 通常 不 会 
正常 终结 。 比 如 ， 它 们 的 执行 体 本 里 束 是 一 个 大 大 的 无 穷 循 坏 ， 用 于 所 
供 某 些 服务 。 


那 如 何 正常 的 关闭 一 个 线程 呢 ? 查 阅 JDK， 你 不 难 发 现 Thread 提 供 
了 一 个 stop(0 方 法 。 如 有 果 你 使 用 stop() 方 法 ， 融 可 以 立即 将 一 个 线程 终 
止 ， 非 常 方便 。 但 如 果 你 使 用 的 是 eclipse 之 类 的 IDE 写 代码 的 话 ， 就 会 
立即 发 现 stop() 方 法 是 一 个 被 标注 为 废弃 的 方法 。 也 就 是 说 ， 在 将 来 ， 
JDK 可 能 就 会 移 除 该 方法 。 

为 什么 stop0) 被 废弃 而 不 推荐 使 用 呢 ? 原因 是 stop(0) 方 法 太 过 于 暴 
力 ， 强 行 把 执行 到 一 半 的 线程 终止 ， 可 能 会 引起 一 些 数据 不 一 致 的 问 


jel 


为 了 让 大 家 更 好 地 理解 本 节 内 容 ， 我 先 简单 介绍 一 些 有 关 数 据 不 一 
致 的 概念 。 假 设 我 们 在 数据 库 里 维护 着 一 张 用 户 表 ， 里 面 记 录 了 用 户 ID 
和 用 户 名 。 假 设 ， 这 里 有 两 条 记录 : 
记录 1: ID=1，NAME= 小 明 
记录 2: ID=2，NAME= 小 王 


如 果 我 们 用 一 个 User 对 象 去 保存 这 些 记 录 ， 我 们 总 是 希望 这 个 对 象 











要 么 保存 记录 1， 要 么 保存 记录 2。 如 果 这 个 User 对 象 一 半 存 着 记录 1， 

另外 一 半 存 在 记录 2， 我 想 大 部 分 人 都 会 抓 狂 吧 ! 如 果 现 在 真 的 由 于 程 
序 问题 ， 出 现 了 这 么 一 个 怪异 的 对 象 u，u 的 ID 是 1， 但 是 u 的 Name 是 小 
王 。 那 么 ， 我 们 说 ， 在 这 种 情况 下 ， 数 据 就 已 经 不 一 致 了 了。 说白 了 就 是 
系统 有 错误 了 。 这 种 情况 是 相当 危险 的 ， 如 果 我 们 把 一 个 不 一 致 的 数据 
直接 写 入 了 数据 库 ， 那 么 就 会 造成 数据 永久 地 被 破坏 和 丢失 ， 后 果 不 去 


设想 。 








也 许 有 人 会 问 ， 怎 么 可 能 呢 ? 跑 得 好 好 的 系统 ， 怎 么 会 出 这 种 问题 
呢 ? 在 单线 程 环境 中 ， 确 实 不 会 ， 但 在 并 行程 序 中 ， 如 果 考 虑 不 周 ， 就 
有 可 能 出 现 类 似 的 情况 。 不 经 思考 地 使 用 stop0 就 有 可 能 导致 这 种 问 


jel 





Thread.stop() 方 法 在 结束 线程 时 ， 会 直接 终止 线程 ， 并 且 会 并 即 释 
放 这 个 线程 所 持 有 的 锁 。 而 这 些 锁 恰 恰 是 用 来 维持 对 象 一 致 性 的 。 如 果 
此 时 ， 写 线程 写 入 数据 正 写 到 一 半 ， 并 强行 终止 ， 那 么 对 象 束 会 被 写 
坏 ， 同 时 ， 由 于 锁 已 经 被 释放 ， 另 外 一 个 等 待 该 锁 的 读 线 程 就 顺理成章 
的 读 到 了 这 个 不 一 致 的 对 象 ， 莫 剧 也 就 此 发 生 。 整 个 过 程 如 图 2.4 所 
示 。 
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图 2-4 stop() 方法 强行 终止 线程 导致 数据 不 一 致 


首先 ， 对 象 u 持 有 ID 和 NAME 两 个 字段 ， 简 单 起 见 ， 这 里 假设 当 ID 
等 于 NAME 时 表示 对 象 是 一 致 的 ， 否 则 表示 对 象 出 错 。 写 线程 总 是 会 将 
ID 和 NAME 写 成 相同 的 值 ， 并 且 在 这 里 初始 值 都 为 0。 当 写 线程 在 写 对 
象 时 ， 读 线程 由 于 无 法 获得 锁 ， 因 此 必须 等 待 ， 所 以 读 线程 是 看 不 见 一 
个 写 了 一 半 的 对 象 的 。 当 写 线程 写 完 ID 后 ， 很 不 幸 地 被 sop0， 此 时 对 
象 U 的 ID 为 1 而 NAME 仍 然 为 0， 处 于 不 一 致 状态 。 而 被 终止 的 写 线程 简 
单 地 将 锁 释 放 ， 读 线程 争夺 到 锁 后 ， 读 取 数 据 ， 于 是 ， 读 到 了 ID=1 而 
NAME=0 的 错误 值 。 














这 个 过 程 可 以 用 以 下 代码 模拟 ， 这 里 读 线 程 ReadObjectThread 在 读 
到 对 象 的 D 和 NAME 不 一 致 时 ， 会 输出 这 些 对 象 。 而 写 线程 
ChangeObjectThread 总 是 会 写 入 两 个 相同 的 值 。 注 意 ， 代 码 在 第 56 行 会 
通过 stop(0 方 法 强行 终止 写 线程 。 


01 public class StopThreadUnsafe { 


02 
03 
04 
05 
06 
07 
08 
09 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 


public static User u=new User(); 
public static class User{ 
private int id; 
private String name; 
public User(){ 
id=0; 
name="0"; 
} 
// 省 略 setter 和 getter 方 法 





} 


@Override 
public String toString() { 


return “User [id=" + id + ", name=" + name + "]"; 


} 
public static class ChangeObjectThread extends Thread{ 


@Override 
public void run(){ 
while(true) { 
synchronized(u) { 
int v=(int)(System.currentTimeMillis()/100 
u.setid(v); 
//Oh, do sth. else 
Cry af 
Thread.sleep(100); 
} catch (InterruptedException e) { 


e.printStackTrace(); 


29 
30 
31 
32 
33 
34 
35 
36 
37 
38 
39 
40 
41 
42 
43 
44 
45 
46 
47 
48 
49 
50 
51 
52 
53 
54 
55 


u.setName(String.valueOf(v)); 


} 
Thread.yield(); 


public static class ReadobjectThread extends Thread{ 
@Override 
public void run(){ 
while(true) { 
synchronized(u) { 
if(u.getId() != Integer.parseInt(u.getName 


System.out.println(u.toString()); 


} 
Thread.yield(); 


public static void main(String[] args) throws InterruptedE 
new ReadObjectThread().start(); 
while(true) { 
Thread t=new ChangeObjectThread(); 
t.start(); 


Thread.sleep(150); 


56 t.stop(); 








执行 以 上 代码 ， 可 以 很 容易 得 到 类 似 如 下 输出 ，ID 和 NAME 产 生 了 
大 二 人 


User [1d=1425135593, name=1425135592 | 
User [1d=1425135594, name=1425135593] 





如 果 在 线 上 环境 跑 出 以 上 结果 ， 那 么 加 班 加 点 估计 古 免 不 了 了 ， 因 
为 这 类 问题 一 旦 出 现 ， 残 很 难 排 查 ， 因 为 它们 甚至 没有 任何 错误 信息 ， 
也 没有 线程 堆栈 。 这 种 情况 一 旦 混杂 在 动 则 十 几 万 行 的 程序 代码 中 时 ， 
发 现 它们 就 全 和 凭 经 验 、 时 间 还 有 一 点 点 运气 了 。 因 此 ， 除 非 你 很 清楚 你 
在 做 什么 ， 否 则 不 要 随便 使 用 stop(0 方 法 来 停止 一 个 线程 。 











那 如 果 需 要 停止 一 个 线程 时 ， 应 该 这 么 做 呢 ? 其 实 方法 很 简单 ， 只 
是 需要 由 我 们 自行 决定 线程 何 时 退出 就 可 以 了 。 仍 然 用 本 例 说 明 ， 只 需 
要 将 ChangeObjectThread 线 程 增加 一 个 stopMe() 方 法 即 可 。 如 下 所 示 : 


01 public static class ChangeObjectThread extends Thread { 


02 volatile boolean stopme = false; 
03 

04 public void stopMe(){ 

05 stopme = true; 

06 } 


07 @Override 


08 public void run() { 


09 while (true) { 

10 if (stopme) { 

11 System.out.printin("exit by stop me"); 
12 break; 

1g } 

14 synchronized (u) { 

15 int v = (int) (System.currentTimeMillis() / 10 
16 u.setId(v); 

17 //Oh, do sth. else 

18 try { 

19 Thread.sleep(100); 

20 } catch (InterruptedException e) { 

21 e.printStackTrace(); 

22 } 

23 u.setName(String.valueOf(v)); 

24 } 

25 Thread. yield(); 

26 } 

27 } 

28 } 








代码 第 2 行 ， 定 义 了 一 个 标记 变量 stopme， 用 于 指示 线程 是 否 需 要 
退出 。 当 stopMe0 方 法 被 调用 ，stopme 就 被 设置 为 tue， 此 时 ， 在 代码 第 
10 行 检测 到 这 个 改动 时 ， 线 程 就 自然 退出 了 。 使 用 这 种 方式 退出 线程 ， 
不 会 使 对 象 u 的 状态 出 现 错误 。 因 为 ，ChangeObjectThread 已 经 没有 机 
会 “ 写 坏 ” 对 象 了 ， 它 总 是 会 选择 在 一 个 合适 的 时 间 终 止 线程 。 


2.2.3 Zaher 


在 Java 中 ， 线 程 中 断 是 一 种 重要 的 线程 协作 机 制 。 从 表面 上 理解 ， 
中 断 就 是 让 目标 线程 停止 执行 的 意思 ， 实 际 上 并 非 完 全 如 此 。 在 上 一 节 
中 ， 我 们 己 经 详细 讨论 了 stop(0) 方 法 停止 线程 的 害处 ， 并 且 使 用 了 一 矢 
目 有 的 机 制 完善 线程 退出 的 功能 。 那 在 JDK 中 是 否 有 提供 更 强大 的 支持 
Ne? 答案 是 肯定 的 ， 那 就 是 线程 中 断 。 





严格 地 讲 ， 线 程 中 断 并 不 会 使 线程 立即 退出 ， 而 是 给 线程 发 送 一 个 
通知 ， 告 知 目标 线程 ， 有 人 希望 你 退出 啦 ! 至 于 目标 线程 接 到 通知 后 如 
何 处 理 ， 则 完全 由 目标 线程 自行 决定 。 这 点 很 重要 ， 如 条 中 断后 ， 线 程 
立即 无 条 件 退 出 ， 我 们 整 义 会 遇 到 stop0 方 法 的 老 问 题 。 











与 线程 中 断 有 关 的 ， 有 三 个 方法 ， 这 三 个 方法 看 起 来 很 像 ， 所 以 可 
能 会 引起 混 消 和 误 用 ， 和 硕 望 大 家 注意 。 


public void Thread.interrupt() // 中 断 线 程 
public boolean Thread.isInterrupted() // 判断 是 否 被 中 断 


public static boolean Thread.interrupted() // 判断 是 否 被 中 断 ， 并 清 | 





Thread.interrupt() 方 法 是 一 个 实例 方法 。 它 通知 目标 线程 中 断 ， 也 就 
是 设置 中 断 标 志 位 。 中 断 标 志 位 表示 当前 线程 已 经 被 中 断 了 。 
Thread.isInterrupted() 方 法 也 是 实例 方法 ， 它 判断 当前 线程 是 否 有 被 中 断 
《通过 检查 中 断 标 志 位 ) 。 最 后 的 静态 方法 Thread.interruptedO 也 是 用 来 
判断 当前 线程 的 中 断 状 态 ， 但 同时 会 清除 当前 线程 的 中 断 标 志 位 状态 。 


下 面 这 段 代码 对 t1 线 程 进行 了 中 断 ， 那 么 中 断后 ，t1 会 停止 执行 
吗 ? 





public static void main(String[] args) throws InterruptedExceptio 
Thread ti=new Thread(){ 
@Override 
public void run(){ 
while(true) { 


Thread. yield(); 


ar 
t1.start(); 
Thread.sleep(2000); 


t1.interrupt(); 





在 这 里 ， 昌 然 对 人 进行 了 中 断 ， 但 是 在 世 中 并 没有 中 断 处 理 的 逻 
辑 ， 因 此 ， 即 使 引线 程 被 置 上 了 中 断 状 态 ， 但 是 这 个 中 断 不 会 发 生 任何 
作用 。 


如 果 和 希望 { 在 中 断后 退出 ， 就 必须 为 它 增加 相应 的 中 断 处 理 代 码 : 


Thread ti=new Thread(){ 
@Override 
public void run(){ 
while(true) { 
if (Thread.currentThread().isInterrupted()){ 
System.out.printin("Interruted!"); 


break; 


Thread.yield(); 


上 述 代 码 的 加 粗 部 分 使 用 Thread.isInterrupted0 函 数 判断 当前 线程 是 
人 否 补 中断 了 ， 如 果 是 ， 则 退出 循环 体 ， 结 束 线程 。 这 看 起 来 与 前 面 增加 
stopme 标 记 的 手法 非常 相似 ， 但 是 中 断 的 功能 更 为 强劲 。 比 如 ， 如 果 在 
循环 体 中 ， 出 现 了 类 似 于 wait0 或 者 sleep(0 这 样 的 操作 ， 则 只 能 通过 中 晰 
来 识别 了 。 


下 面 ， 先 来 了 解 一 下 Thread.sleep(0) 函 数 ， 它 的 签名 如 下 : 


public static native void sleep(long millis) throws InterruptedEx 


Thread.sleep() 方 法 会 让 当前 线程 休眠 耕 干 时 间 ， 它 会 殷 出 一 个 
InterruptedException 中 上 断 异 常 。InterruptedException 不 是 运行 时 异常 ， 也 
就 是 说 程序 必须 捕获 并 且 处 理 它 ， 当 线程 在 sleepO 体 眠 时 ， 如 采 被 中 
Wt, IAS RAMP E. 











01 public static void main(String[] args) throws InterruptedExcep 


02 Thread ti=new Thread(){ 

03 @Override 

04 public void run(){ 

05 while(true){ 

06 if(Thread.currentThread().isInterrupted()){ 
07 System.out.println("Interruted!"); 


08 break; 


09 i 


10 try { 

11 Thread.sleep(2000); 

12 } catch (InterruptedException e) { 

13 System.out.printin("Interruted When Sleep" 
14 // 设 置 中 断 状态 

15 Thread.currentThread().interrupt(); 
16 } 

17 Thread.yield(); 

18 } 

19 } 

20 ae 

21 t1.start(); 

22 Thread.sleep(2000); 

23 t1.interrupt(); 

24 } 


注意 上 述 代码 中 第 10 一 15 行 加 粗 部 分 ， 如 果 在 第 11 行 代码 处 ， 线 程 
被 中 断 ， 则 程序 会 抛 出 异常 ， 并 进入 第 13 行 处 理 。 在 catch 子 句 部 分 ， 由 
于 已 经 捕获 了 中 断 ， 我 们 可 以 立即 退出 线程 。 但 在 这 里 ， 我 们 并 没有 这 
么 做 ， 因 为 也 许 在 这 段 代 码 中 ， 我 们 还 必须 进行 后 续 的 处 理 ， 保 证 数据 
的 一 致 性 和 完整 性 ， 因 此 ， 执 行 了 Thread.interrupt0) 方 法 再 次 中 断 自己 ， 
置 上 中 断 标记 位 。 只 有 这 么 做 ， 在 第 6 行 的 中 断 检 查 中 ， 才 能 发 现 当前 
线程 已 经 被 中 断 了 。 





注意 : Thread. sleep () 方法 由 于 中 断 而 抛 出 异常 ， 此 时 ， 它 会 清除 
中 断 标 记 ， 如 果 不 加 处 理 ， 那 么 在 下 一 次 循环 开始 时 ， 就 无 法 捕获 


这 个 中 断 ， 故 在 异常 处 理 中 ， 再 次 设置 中 断 标 记 位 。 


2.2.4 等 待 Cwait) 和 通知 (notify) 


为 了 文 持 多 线程 之 间 的 协作 ，JDK 提 供 了 两 个 非常 重要 的 接口 线程 
等 待 wait() 方 法 和 通知 notify() 方 法 。 这 两 个 方法 并 不 是 在 Thread 类 中 
的 ， 而 是 输出 Object 类 。 这 也 意味 着 任何 对 象 都 可 以 调用 这 两 个 方法 。 





这 两 个 方法 的 签名 如 下 : 


public final void wait() throws InterruptedException 


public final native void notify() 





当 在 一 个 对 象 实例 上 调用 wait0 方 法 后 ， 当 前 线程 就 会 在 这 个 对 象 
上 等 待 。 这 是 什么 意思 呢 ? 比如 ， 线 程 A 中 ， 调 用 了 obj.wait0 方 法 ， 那 
么 线程 A 就 会 停止 继续 执行 ， 而 转 为 等 待 状态 。 等 待 到 何 时 结束 呢 ? 线 
程 A 会 一 直 等 到 其 他 线程 调用 了 obj.notify() 方 法 为 止 。 这 时 ，obj 对 象 就 
伍 然 成 为 多 个 线程 之 间 的 有 效 通信 手段 。 








那 wait0 和 mnotifyO 究 竟 是 如 何 工作 的 呢 ? 图 2.5 展 示 了 两 者 的 工作 过 
程 。 如 果 一 个 线程 调用 了 object.wait()， 那 么 它 就 会 进入 object 对 象 的 等 
待 队列 。 这 个 等 待 队列 中 ， 可 能 会 有 多 个 线程 ， 因 为 系统 运行 多 个 线程 
同时 等 待 某 一 个 对 象 。 当 object.notify() 被 调用 时 ， 它 就 会 从 这 个 等 待 队 
列 中 ， 随 机 选择 一 个 线程 ， 并 将 其 唤醒 。 这 里 希望 大 家 注意 的 是 ， 这 个 
选择 是 不 公平 的 ， 并 不 是 先 等 待 的 线程 会 优先 被 选择 ， 这 个 选择 完全 是 
随机 的 。 











en re ol 
ss Th | 2 | Va | | / Odjeet utut P/b 
ro 


— 一 一 A 二 
ohjot nafy L) ptb ki | 











ob ject. not! fy A 7. Gorey 
图 2.5 notify () 唤醒 等 待 的 线程 


除了 notify0 方 法 外 ，Object 对 象 还 有 一 个 类 似 的 notifyAll0 方 法 ， 它 
和 notify0O 的 功能 基本 一 致 ， 但 不 同 的 是 ， 它 会 唤醒 在 这 个 等 待 队列 中 所 
有 等 待 的 线程 ， 而 不 是 随机 选择 一 个 。 


这 里 还 需要 强调 一 点 ，Object.wait() 方 法 并 不 是 可 以 随便 调用 的 。 
它 必 须 包 含 在 对 应 的 synchronzied 语 句 中 ， 无 论 是 wait() 或 者 notify() 都 需 
要 首先 获得 目标 对 象 的 一 个 监视 器 。 如 图 2.6 所 示 ， 显 示 了 wait() 和 
notify() 的 工作 流程 细节 。 其 中 Tl1 和 T2 表 示 两 个 线程 。T1 在 正确 执行 
wait() 方 法 前 ， 首 先 必须 获得 object 对 象 的 监视 器 。 而 wait0 方 法 在 执行 
后 ， 会 释放 这 个 监视 器 。 这 样 做 的 目的 是 使 得 其 他 等 竺 在 object 对 象 上 
的 线程 不 至 于 因为 T1 的 休眠 而 全 部 无 法 正常 执行 。 
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图 2.6 wait () 和 notify() 的 工作 流程 细节 


线程 T2 在 notifyO 调 用 前 ， 也 必须 获得 object 的 监视 器 。 所 季 ， 此 时 
Tl 已 经 释放 了 这 个 监视 器 。 因 此 ，T2 可 以 顺利 获得 object 的 监视 器 。 接 
着 ，T2 执 行 了 notify() 方 法 笠 试 唤醒 一 个 等 竺 线程 ， 这 里 假设 唤醒 了 
T1。T1 在 被 唤醒 后 ， 要 做 的 第 一 件 事 并 不 是 执行 后 续 的 代码 ， 而 是 要 
壬 试 重新 获得 object 的 监视 器 ， 而 这 个 监视 器 也 正 是 T1 在 wait(0) 方 法 执行 
前 所 持 有 的 那个 。 如 果 暂 时 无 法 获得 ，T1 还 必须 要 等 待 这 个 监视 器 。 当 
监视 器 顺利 获得 后 ，T1 才 可 以 真正 意义 上 的 继续 执行 。 








为 了 方便 大 家 理解 ， 这 里 给 出 一 个 简单 地 使 用 wait0 和 mnotify0O 的 案 
例 : 


01 public class SimplewN { 


02 final static Object object = new Object(); 


03 public static class T1 extends Thread{ 

04 public void run() 

05 { 

06 synchronized (object) { 

07 System.out.println(System.currentTimeMillis()+ 
08 try { 

09 System.out.println(System.currentTimeMilli 
10 object.wait(); 

11 } catch (InterruptedException e) { 

12 e.printStackTrace(); 

13 } 

14 System.out.println(System.currentTimeMillis()+ 
15 } 

16 } 

17 } 

18 public static class T2 extends Thread{ 

19 public void run() 

20 { 

21 synchronized (object) { 

22 System.out.println(System.currentTimeMillis()+ 
thread"); 

23 object.notify(); 

24 System.out.println(System.currentTimeMillis()+ 
25 try { 

26 Thread.sleep(2000) ; 

27 } catch (InterruptedException e) { 

28 } 


29 } 


30 } 

31 } 

32 public static void main(String[] args) { 
33 Thread ti = new T1() ; 

34 Thread t2 = new T2() ; 

35 ti.start(); 

36 t2.start(); 

37 } 

38 } 


上 述 代 码 中 ， 开 局 了 两 个 线程 T1 和 T2。T1 执 行 了 object.wait() 方 
法 。 注 意 ， 在 程序 第 6 行 ， 执 行 wait() 方 法 前 ，T1 先 申请 object 的 对 象 
锁 。 因 此 ， 在 执行 objectwaitO0 时 ， 它 是 持 有 object 的 锁 的 。waitO) 方 法 执 
行 后 ，T1 会 进行 等 待 ， 并 释放 object 的 锁 。T2 在 执行 notify0 之 前 也 会 先 
获得 object 的 对 象 锁 。 这 里 为 了 让 实验 效果 明显 ， 特 意 安 排 在 notify0O 执 
行 之 后 ， 让 T2 体 眠 2 秒 钟 ， 这 样 做 可 以 更 明显 地 说 明 ，T1 在 得 到 notify() 
通知 后 ， 还 是 会 先 党 试 重新 获得 object 的 对 象 锁 。 上 述 代 码 的 执行 结 
类 似 如 下 : 


1425224592258:T1 start! 

1425224592258:T1 wait for object 
1425224592258:T2 start! notify one thread 
1425224592258:T2 end! 

1425224594258:T1 end! 


注意 程序 打印 的 时 间 戳 信息， 可 以 看 到 ， 在 T2 通 知 T1 继 续 执行 
后 ，T1 并 不 能 立即 继续 执行 ， 而 是 要 等 待 T2 释 放 object 的 锁 ， 并 重新 成 


功 获得 锁 后 ， 才 能 继续 执行 。 因 此 ， 加 粗 部 分 时 间 惟 的 间隔 为 2 秒 〈 因 
为 T2 休 眠 了 2 秒 ) 。 


JER: Object. wait () 和 Thread. sleep O 方法 都 可 以 让 线程 等 待 若 
干 时 间 。 除 了 wait () 可 以 被 唤醒 外 ， 另 外 一 个 主要 区 别 就 是 wait () 
方法 会 释放 目标 对 象 的 锁 ， 而 Thread. sleep) 方法 不 会 释放 任何 资 
源 。 


2.2.5 FEE (suspend) 和 继续 执行 
(resume) 线程 


如 果 你 阅读 JDK 有 关 Thread 类 的 API 文 档 ， 可 能 还 会 发 现 两 个 看 起 
来 非常 有 用 的 接口 ， 即 线程 挂 起 (suspend) 和 继续 执行 (resume) 。 这 
两 个 操作 是 一 对 相反 的 操作 ， 被 挂 起 的 线程 ， 必 须要 等 到 resume() 操 作 
后 ， 才 能 继续 指定 。 乍 看 之 下 ， 这 对 操作 就 像 Thread.stop() 方 法 一 样 好 
用 。 但 如 果 你 仔细 阅读 文档 说 明 ， 会 发 现 它们 也 早已 被 标注 为 废弃 方 
法 ， 并 不 推荐 使 用 。 





不 推荐 使 用 suspend0O 去 挂 起 线程 的 原因 ， 是 因为 Suspend0 在 导致 线 
程 暂停 的 同时 ， 并 不 会 去 释放 任何 锁 资 源 。 此 时 ， 其 他 任何 线程 想 要 访 
问 被 它 暂 用 的 锁 时 ， 都 会 被 牵连 ， 导 致 无 法 正常 继续 运行 《如 图 2.7 所 
示 ) 。 直 到 对 应 的 线程 上 进行 了 resume() 操 作 ， 被 挂 起 的 线程 才能 继 
续 ， 从 而 其 他 所 有 阻塞 在 相关 锁 上 的 线程 也 可 以 继续 执行 。 但 是 ， 如 果 
resume0 操 作 意 外 地 在 suspend0 前 就 执行 了 ， 那 么 被 挂 起 的 线程 可 能 很 
难 有 机 会 被 继续 执行 。 并 且 ， 更 严重 的 是 : 它 所 占用 的 锁 不 会 被 释放 ， 
因此 可 能 会 导致 整个 系统 工作 不 正常 。 而 且 ， 对 于 被 挂 起 的 线程 ， 从 它 





的 线程 状态 上 看 ， 居 然 还 是 Runnable， 这 也 会 严重 影响 我 们 对 系统 当前 
状态 的 判断 。 
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图 2.7 suspend() 方法 导致 线程 进入 类 似 死 锁 的 状态 









为 了 方便 大 家 理解 suspend() 的 问题 ， 这 里 准备 一 个 简单 的 程序 。 演 
示 了 这 种 情况 : 


01 public class BadSuspend { 


02 public static Object u = new Object(); 

03 static ChangeObjectThread t1 = new ChangeObjectThread("t1i" 
04 static ChangeObjectThread t2 = new ChangeObjectThread("t2" 
05 

06 public static class ChangeObjectThread extends Thread { 

07 public ChangeObjectThread(String name){ 

08 super . setName (name); 

09 } 

10 @Override 

ul public void run() { 


12 synchronized (u) { 


13 System.out.println("in "+getName()); 


14 Thread.currentThread().suspend(); 
15 } 

16 } 

17 } 

18 

19 public static void main(String[] args) throws InterruptedE 
20 ti.start(); 

21 Thread.sleep(100) ; 

22 t2.start(); 

23 t1.resume(); 

24 t2.resume(); 

25 t1.join(); 

26 t2.join(); 

27 } 

28 } 
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实现 对 临界 区 的 访问 。 线 程 tt 和 t2 启 动 后 ， 在 主 函数 中 ， 第 23 一 24 行 ， 
对 其 进行 resume0O。 目 的 是 让 他 们 得 以 继续 执行 。 接 着 ， 主 函数 等 待 着 
两 个 线程 的 结束 。 


执行 上 述 代 码 后 ， 我 们 可 能 会 得 到 以 下 输出 : 


in t1 


in t2 








这 表明 两 个 线程 先后 进入 了 临界 区 。 但 是 程序 不 会 退出 。 而 是 会 挂 


起 。 使 用 jstack 命 令 打印 系统 的 线程 信息 可 以 看 到 : 


"t2" #9 prio=5 os_prio=0 tid=0x15c85c00 nid=0xiddc runnable [0x15 
java.lang.Thread.State: RUNNABLE 
at java.lang.Thread.suspendO(Native Method) 
at java.lang.Thread.suspend(Thread.java:1029) 
at geym.conc.ch2.suspend.BadSuspend$ChangeObjectThread.ru 
- locked <O0x048b2e58> (a java.lang.Object) 
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的 线程 状态 确实 是 RUNNABLE， 这 很 有 可 能 使 我 们 误 判 当前 系统 的 状 
态 。 同 时 ， 虽 然 主 函数 中 已 经 调用 了 resume0， 但 是 由 于 时 间 先 后 顺序 
的 缘故 ， 那 个 resume 并 没有 生效 ! 这 就 导致 了 线程 2 被 永远 挂 起 ， 并 且 
水 远 占用 了 对 象 u 的 锁 。 这 对 于 系统 来 说 极 有 可 能 是 致命 的 。 


如 果 需 要 一 个 比较 可 靠 的 suspend0 函 数 ， 那 应 该 怎么 办 呢 ? 回想 一 
下 上 一 节 中 提 到 的 wait0 和 notify0 方 法 ， 这 也 不 是 一 件 难 事 。 下 面 的 代 
码 就 给 出 了 一 个 利用 wait0 和 notify0 方 法 ， 在 应 用 层面 实现 suspend0 和 
resume() 功 能 的 例子 。 


01 public class GoodSuspend { 


02 public static Object u = new Object(); 

03 

04 public static class ChangeObjectThread extends Thread { 
05 volatile boolean suspendme = false; 

06 

07 public void suspendMe() { 


08 suspendme = true; 


09 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 
32 
33 
34 
35 


public void resumeMe(){ 
suspendme=false; 
synchronized (this) { 


notify(); 


Í 


@Override 
public void run() { 


while (true) { 


synchronized (this) { 
while (Suspendme ) 
try { 
wait(); 
} catch (InterruptedException e) { 


e.printStackTrace(); 


synchronized (u) { 
System.out.printin("in ChangeObjectThread" 


} 
Thread.yield(); 


public static class ReadObjectThread extends Thread { 
@Override 
public void run() { 
while (true) { 
synchronized (u) { 
System.out.printin("in ReadObjectThread"); 


} 
Thread.yield(); 


public static void main(String[] args) throws InterruptedE 
ChangeObjectThread ti = new ChangeObjectThread(); 
ReadObjectThread t2 = new ReadObjectThread(); 
ti.start(); 
t2.start(); 
Thread.sleep(1000) ; 
t1.suspendMe(); 
System.out.println("suspend ti 2 sec"); 
Thread.sleep(2000) ; 
System.out.printin("resume t1"); 


t1.resumeMe(); 


在 代码 第 5 行 ， 给 出 一 个 标记 变量 suspendme， 表 示 当 前 线程 是 否 被 
挂 起 。 同 时 ， 增 加 了 suspendMe() 和 resumeMe0) 两 个 方法 ， 分 别 用 于 挂 起 
线程 和 继续 执行 线程 。 








在 代码 第 21 一 28 行 ， 线 程 会 先 检查 自己 是 否 被 挂 起 ， 如 果 是 ， 则 执 
行 wait0 方 法 进行 等 待 。 人 否则 ， 则 进行 正常 的 处 理 。 当 线程 继续 执行 
时 ，resumeMe0) 方 法 被 调用 《代码 第 11 一 16 行 ) ， 线 程 t1 得 到 一 个 继续 
执行 的 notify() 通 知 ， 并 且 清 除了 挂 起 标记 ， 从 而 得 以 正常 执行 。 


2.2.6 ”等 行 线程 结束 (join) 和 谦让 
(yield ) 








在 很 多 情况 下 ， 线 程 之 间 的 协作 和 人 与 人 之 间 的 协作 非常 类 似 。 一 
种 非 第 第 见 的 合作 方式 束 是 分 工 合作 。 以 我 们 非常 熟悉 的 软件 开 友 为 
例 ， 在 一 个 项 目 进行 时 ， 总 是 应 该 有 儿 位 号 称 古 “ 需 求 分 析 师 ”的 同事 ， 
先 对 系统 的 需求 和 功能 点 进行 整理 和 总 结 ， 然 后 ， 以 书面 形式 给 出 一 份 
需求 说 明 或 者 类 似 的 参考 文档 ， 然 后 ， 软 件 设计 师 、 研 发 工程 师 才 会 一 
拥 而 上 ， 进 行 软件 开发 。 如 采 缺 少 需求 分 析 师 的 工作 和 输出， 那么 软件 研 
发 的 难度 可 能 会 比较 大 。 因 此 ， 作 为 一 名 软件 研发 人 员 ， 总 是 喜欢 等 符 
再 求 分 析 师 完成 他 应 该 完成 的 任务 后 ， 才 愿意 投 呈 工作。 简单 地 次 ， 就 
古 研 发 人 员 需 要 等 符 需 求 分 析 师 完成 他 的 工作 ， 然 后 ， 才 能 进行 研 友 。 


























将 这 个 关系 对 应 到 多 线程 应 用 中 ， 很 多 时 候 ， 一 个 线程 的 输入 可 能 
非常 依赖 于 另外 一 个 或 者 多 个 线程 的 输出 ， 此 时 ， 这 个 线程 就 需要 等 待 
依赖 线程 执行 完毕 ， 才 能 继续 执行 。JDK 提 供 了 join0 操 作 来 实现 这 个 功 
能 ， 如 下 所 示 ， 显 示 了 2 个 join() 方 法 : 





public final void join() throws InterruptedException 


public final synchronized void join(long millis) throws Interrupt 


第 一 个 join( 方 法 表示 无 限 等 待 ， 它 会 一 直 阻塞 当前 线程 ， 直 到 月 
标 线程 执行 完毕 。 第 二 个 方法 给 出 了 一 个 最 大 等 待 时 间 ， 如 果 超 过 给 定 
时 间 目 标 线程 还 在 执行 ， 当 前 线程 也 会 因为 “等 不 及 了 ”， 而 继续 往 下 执 
行 。 











英文 join 的 翻译 ， 通 向 是 加 入 的 意思 。 在 这 里 感觉 也 非常 贴切 。 
为 一 个 线程 要 加 入 另外 一 个 线程 ， 那 么 最 好 的 方法 就 是 等 着 它 一 起 走 。 








这 里 提供 一 个 简单 点 的 join0 实 例 ， 供 大 家 参考 : 


public class JoinMain { 
public volatile static int i=0; 
public static class AddThread extends Thread{ 
@Override 
public void run() { 


for(i=0;1<10000000; i++); 


} 

public static void main(String[] args) throws InterruptedExce 
AddThread at=new AddThread(); 
at.start(); 
at.join(); 


System.out.println(1); 


主 函 数 中 ， 如 果 不 使 用 join0 等 待 AddThread， 那 么 得 到 的 ji 很 可 能 是 
0 或 者 一 个 非常 小 的 数字 。 因 为 AddThread 还 没 开 始 执行 ，i 的 值 就 已 经 
被 输出 了 。 但 在 使 用 join(0) 方 法 后 ， 表 示 主 线程 愿意 等 待 AddThread 执 行 
完毕 ， 跟 着 AddThread 一 起 往 前 走 ， 故 在 join0 返 回 时 ，AddThread 已 经 
执行 完成 ， 故 i 总 是 10000000。 


有 关 join()， 我 还 想 再 补充 一 点 ，join() 的 本 质 是 让 调用 线程 wait() 在 
当前 线程 对 象 实例 上 。 下 面 是 JDK 中 join(0) 实 现 的 核心 代码 片段 : 


while (isAlive()) { 
wait(0); 





可 以 看 到 ， 它 让 调用 线程 在 当前 线程 对 象 上 进行 等 待 。 当 线程 执行 
完成 后 ， 被 等 待 的 线程 会 在 退出 前 调用 notifyAll10 通 知 所 有 的 等 待 线程 
继续 执行 。 因 此 ， 值 得 注意 的 一 点 是 : 不 要 在 应 用 程序 中 ， 在 Thread 对 
象 实例 上 使 用 类 似 wait0) 或 者 notify0 等 方法 ， 因 为 这 很 有 可 能 会 影响 系 
统 API 的 工作 ， 或 者 被 系统 API 所 影响 。 





另外 一 个 比较 有 趣 的 方法 ， 是 Thread.yield()， 它 的 定义 如 下 : 
public static native void yield(); 


这 是 一 个 静态 方法 ， 一 旦 执行 ， 它 会 使 当前 线程 让 出 CPU。 但 要 注 
意 ， 让 出 CPU 并 不 表示 当前 线程 不 执行 了 。 当 前 线程 在 让 出 CPU 后 ， 还 
会 进行 CPU 资源 的 和 争夺， 但 是 是 否 能 够 再 次 被 分 配 到 ， 就 不 一 定 了 。 因 
此 ， 对 Thread.yieldO) 的 调用 就 好 像 是 在 说 : 我 已 经 完成 一 些 最 重要 的 工 
作 了 ， 我 应 该 是 可 以 休 一 下 了 ， 可 以 给 其 他 线程 一 些 工 作 机 会 啦 ! 





如 果 你 觉得 一 个 线程 不 那么 重要 ， 或 者 优先 级 非常 低 ， 而 且 又 害怕 
它 会 占用 太 多 的 CPU 资源 ， 那 么 可 以 在 适当 的 时 候 调 用 Thread.yield0)， 
给 予 其 他 重要 线程 更 多 的 工作 机 会 。 


2.3 volatile 与 Java 内 存 模型 
(JMM) 


之 前 已 经 简单 介绍 了 Java 内 存 模型 JMM) ，Java 内 存 模 型 都 是 围 
绕 着 原子 性 、 有 序 性 和 可 见 性 展开 的 。 大 家 可 以 先 回顾 一 下 上 一 章 中 的 
相关 内 容 。 为 了 在 适当 的 场合 ， 确 保 线程 间 的 有 序 性 、 可 见 性 和 原子 
性 。Java 使 用 了 一 些 特殊 的 操作 或 者 关键 字 来 申明 、 告 诉 虚 拟 机 ， 在 这 
个 地 方 ， 要 尤其 注意 ， 不 能 随意 变动 优化 目标 指令 。 关 键 字 volatile 就 是 
HRZ 











如 果 你 查阅 一 下 英文 字典 ， 有 关 volatile 的 解释 ， 你 会 得 到 最 常用 的 
解释 是 “ 易 变 的 ， 不 稳定 的 ?。 这 也 正 是 使 用 volatile 关 键 字 的 语义 。 


当 你 用 volatile 去 申明 一 个 变量 时 ， 就 等 于 告诉 了 虚拟 机 ， 这 个 变量 
极 有 可 能 会 被 某 些 程序 或 者 线程 修改 。 为 了 确保 这 个 变量 被 修改 后 ， 应 
用 程序 范围 内 的 所 有 线程 都 能 够 "看 到 * 这 个 改动 ， 虚 执 机 就 必须 采用 一 
些 特殊 的 手段 ， 保 证 这 个 变量 的 可 见 性 等 特点 。 





比如 ， 根 据 编 译 器 的 优化 规则 ， 如 宋 不 使 用 volatile 申 明 变 量 ， 那 么 
这 个 变量 被 修改 后 ， 其 他 线程 可 能 并 不 会 被 通知 到 ， 甚 至 在 别 的 线程 
中 ， 看 到 变量 的 修改 顺序 都 会 是 反 的 。 但 一 旦 使 用 volatile， 虚 拟 机 就 会 
特别 小 心地 处 理 这 种 情况 。 


大 家 应 该 对 上 一 章 中 介绍 原子 性 时 ， 给 出 的 MultiThreadLong 案 例 还 
记忆 犹 新 吧 ! RE, 没有 人 愿意 束 这 么 把 数据 “ 写 坏 ”。 那 这 种 情况 ， 应 
该 怎么 处 理 才 能 保证 每 次 写 进去 的 数据 不 坏 呢 ?最 简单 的 一 种 方法 就 是 








加 入 volatile 申 明 ， 告 诉 编译 器 ， 这 个 long 型 数据 ， 你 要 格外 小 心 ， 因 为 
他 会 不 断 地 被 修改 。 





下 面 的 代码 片段 显示 了 volatile 的 使 用 ， 限 于 篇 幅 ， 这 里 不 再 给 出 完 
整 代码 ; 


public class MultiThreadLong { 
public volatile static long t=0; 
public static class ChangeT implements Runnable{ 


private long to; 


从 这 个 案例 中 ， 我 们 可 以 看 到 ，volatile 对 于 保证 操作 的 原子 性 是 有 
非常 大 的 帮助 的 。 但 是 需要 注意 的 是 ，volatile 并 不 能 代 蔡 锁 ， 它 也 无 法 
保证 一 些 复 合 操 作 的 原子 性 。 比 如 下 面 的 例子 ， 通 过 volatile 是 无 法 保证 
it+ 的 原子 性 操作 的 : 





01 static volatile int i=0; 


02 public static class PlusTask implements Runnable{ 


03 @Override 

04 public void run() { 

05 for(int k=0;k<10000; k++) 
06 i++; 

07 } 

08 } 

09 


10 public static void main(String[] args) throws InterruptedExcep 


ial Thread[] threads=new Thread[10]; 


12 for(int i=0;i<10;i++){ 


13 threads[i]=new Thread(new PlusTask()); 
14 threads[i].start(); 

15 } 

16 for(int i=0;i<10;i++){ 

17 threads[i].join(); 

18 } 

19 

20 System.out.println(i); 

21 } 


执行 上 述 代 码 ， 如 果 第 6 行 i++ 是 原子 性 的 ， 那 么 最 终 的 值 应 该 是 
100000 〈10 个 线程 各 累加 10000 次 ) 。 但 实际 上 ， 上 述 代 码 的 输出 总 是 
会 小 于 100000。 





此 外 ，volatile 也 能 保证 数据 的 可 见 性 和 有 序 性 。 下 面 再 来 看 一 个 简 
单 的 例子 : 


01 public class NoVisibility { 


02 private static boolean ready; 

03 private static int number; 

04 

05 private static class ReaderThread extends Thread { 
06 public void run() { 

07 while (!ready); 

08 System.out.println(number); 

09 } 


10 7 


12 public static void main(String[] args) throws InterruptedE 
13 new ReaderThread().start(); 

14 Thread.sleep(1000); 

15 number = 42; 

16 ready = true; 

17 Thread.sleep(10000) ; 

18 } 

19 } 


ERREF, a a a Nai 
true) ， 才 会 打印 number 的 值 。 它 通过 ready 变 量 判断 是 否 应 该 打印 。 在 
主线 程 中 ， 开 司 ReaderThread 后 ， ce ae: 并 期 望 
ReaderThread 能 够 看 到 这 些 变化 并 将 数据 输出 。 


在 虚拟 机 的 Client 模 式 下 ， 由 于 JIT 并 没有 做 足够 的 优化 ， 在 主线 程 
修改 ready 变 量 的 状态 后 ，ReaderThread 可 以 发 现 这 个 改动 ， 并 退出 程 
序 。 但 是 在 Server 模 式 下 ， 由 于 系统 优化 的 结果 ，ReaderThread 线 程 无 
法 “看 到 ”主线 程 中 的 人 修改， 导致 ReaderThread 水 远 无 法 退出 (因为 代码 
第 7 行 判 断 永 远 不 会 成 立 ) ， 这 显然 不 是 我 们 想 看 到 的 结果 。 这 个 问题 
就 是 一 个 典型 的 可 见 性 问题 。 


YER: 可 以 使 用 Java 虚 拟 机 参数 -server 切 换 到 Server 模 式 。 


和 原子 性 问题 一 样 ， 我 们 只 要 简单 地 使 用 volatile 来 申明 ready 变 
量 ， 告 诉 Java 虚 拟 机 ， 这 个 变量 可 能 会 在 不 同 的 线程 中 修改 。 这 样 ， 束 
可 以 顺利 解决 这 个 问题 了 。 


2.4 分门别类 的 管理 : 线程 组 


竺 一 个 系统 中 ， 如 果 线 程 数量 很 多 ， 而 且 功 能 分 配 比较 明确 ， 束 可 
以 将 相同 功能 的 线程 放置 在 一 个 线程 组 里 。 打 个 比方 ， 如 果 你 有 一 个 全 
果 ， 你 就 可 以 把 它 拿 在 手 里 ， 但 是 如 果 你 有 十 个 人 苹果， 你 就 最 好 还 有 一 
个 篮子 ， 人 否则 不 方便 携带 。 对 于 多 线程 来 说 ， 也 是 这 个 道理 。 想 要 轻松 
处 理 几 十 个 甚至 上 百 个 线程 ， 最 好 还 是 将 它们 都 效 进 对 应 的 篮子 里 。 














线程 组 的 使 用 非常 简单 ， 如 下 : 


01 public class ThreadGroupName implements Runnable { 


02 public static void main(String[] args) { 

03 ThreadGroup tg = new ThreadGroup("PrintGroup"); 

04 Thread ti = new Thread(tg, new ThreadGroupName(), "T1" 
05 Thread t2 = new Thread(tg, new ThreadGroupName(), "T2" 
06 t1.start(); 

07 t2.start(); 

08 System.out.printin(tg.activeCount()); 

09 tg.list(); 

10 } 

11 

12 @Override 

13 public void run() { 

14 String groupAndName=Thread.currentThread().getThreadGr 
15 + "-" + Thread.currentThread().getName(); 


16 while (true) { 


17 System.out.println("I am " + groupAndName) ; 


18 Cig 

19 Thread.sleep( 3000); 

20 } catch (InterruptedException e) { 
21 e.printStackTrace(); 

22 J 

23 } 

24 } 

25 } 


上 述 代 码 第 3 行 ， 建 立 一 个 名 为 “PrintGroup” 的 线程 组 ， 并 将 T1 和 T2 
两 个 线程 加 入 这 个 组 中 。 第 8、9 两 行 ， 展示 了 线程 组 的 两 个 重要 的 功 
能 ，activeCount() 可 以 获得 活动 线程 的 总 数 ， 但 由 于 线程 是 动态 的 ， 
此 这 个 值 只 是 一 个 估计 值 ， 无 法 确定 精确 ，list() 方 法 可 以 打印 这 个 线程 
组 中 所 有 的 线程 信息 ， 对 调试 有 一 定 帮助 。 代 码 中 第 4、5 两 行 创建 了 两 
个 线程 ， 使 用 Thread 的 构造 函数 ， 指 定 线程 所 属 的 线程 组 ， 将 线程 和 线 
时 组 关联 起 来 。 











线程 组 还 有 一 个 值得 注意 的 方法 stopO0， 它 会 停止 线程 组 中 所 有 的 
线程 。 这 看 起 来 是 一 个 很 方便 的 功能 ， 但 是 它 会 遇 到 和 Thread.stopO 相 
同 的 问题 ， 因 此 使 用 时 也 需要 格外 谨慎 。 





此 外 ， 对 于 编码 习惯 ， 我 还 想 再 多 说 几 多 。 强 烈 建议 大 家 在 创建 线 
程 和 线程 组 的 时 候 ， 给 它们 取 一 个 好 听 的 名 字 。 对 于 计算 机 来 说 ， 也 许 
名 字 并 不 重要 ， 但 是 在 系统 出 现 问题 时 ， 你 很 有 可 能 会 导出 系统 内 所 有 
线程 ， 你 拿 到 的 如 果 是 一 连 串 的 Thread-0、Thread-1、Thread-2， 我 想 你 
一 定 会 抓 狂 。 但 取而代之 ， 你 看 到 的 如 果 是 类 似 HttpHandler、 
FTPService 这 样 的 名 字 ， 会 让 你 心情 倍 克 。 








2.5 ”驻守 后 台 : 守护 线程 
(Daemon ) 





守护 线程 是 一 种 特殊 的 线程 ， 就 和 它 的 名 字 一 样 ， 它 是 系统 的 守护 
者 ， 在 后 台 上 默默 地 完成 一 些 系统 性 的 服务 ， 比 如 垃圾 回收 线程 、JIT 线 
程 就 可 以 理解 为 守护 线程 。 与 之 相对 应 的 是 用 户 线程 ， 用 户 线程 可 以 认 
为 是 系统 的 工作 线程 ， 它 会 完成 这 个 程序 应 该 要 完成 的 业务 操作 。 如 果 
用 户 线 程 全 部 结束 ， 这 也 意味 着 这 个 程序 实际 上 无 事 可 做 了 。 守 护 线程 
要 守护 的 对 象 已 经 不 存在 了 ， 那 么 整个 应 用 程序 就 目 然 应 该 结束 。 因 
此 ， 当 一 个 Java 应 用 内 ， 只 有 和 守护 线程 时 ，Java 虚 拟 机 就 会 自然 退出 。 























下 面 简单 地 看 一 下 守护 线程 的 使 用 : 


01 public class DaemonDemo { 


02 public static class DaemonT extends Thread{ 

03 public void run(){ 

04 while(true){ 

05 System.out.println("I am alive"); 
06 try { 

07 Thread.sleep(1000); 

08 } catch (InterruptedException e) { 
09 e.printStackTrace(); 

10 } 

11 } 


12 } 


13 


14 public static void main(String[] args) throws InterruptedE 
15 Thread t=new DaemonT(); 

16 t.setDaemon(true); 

17 t.start(); 

18 

19 Thread.sleep( 2000); 

20 } 

24 1) 





上 述 代码 第 16 行 ， 将 线程 t 设 置 为 守护 线程 。 这 里 注意 ， 设 置 守 护 
线程 必须 在 线程 start0) 之 前 设置 ， 任 则 你 会 得 到 一 个 类 似 以 下 的 异常 ， 
告诉 你 守护 线程 设置 失败 。 但 是 你 的 程序 和 线程 依然 可 以 正常 执行 。 只 
征 被 当做 用 户 线 程 而 已 。 因 此 ， 如 宁 不 小 心 忽略 了 下 面 的 异常 信息 ， 你 
就 很 可 能 察觉 不 到 这 个 错误 。 那 你 就 会 证 异 为 什么 程序 永远 停 不 下 来 了 
呢 ? 

















Exception in thread "main" java.lang.IllegalThreadStateException 
at java.lang.Thread.setDaemon(Thread.java:1367 ) 


at geym.conc.ch2.daemon.DaemonDemo.main(DaemonDemo. java: 20) 


在 这 个 例子 中 ， 由 于 t 侯 设置 为 守护 线程 ， 系 统 中 只 有 主线 程 main 
为 用 户 线 程 ， 因 此 在 main 线 程 休 虐 2 秒 后 退出 时 ， 整 个 程序 也 随 之 结 
束 。 但 如 果 不 把 线程 t 设 置 为 守护 线程 ，main 线 程 结束 后 ，t 线 程 还 会 不 
停 地 打印 ， 永 远 不 会 结束 。 


2.6” 抑 干 重要 的 事 : 线程 优先 级 


Java 中 的 线程 可 以 有 目 己 的 优先 级 。 优 先 级 高 的 线程 在 竞争 资源 时 
会 更 有 优势 ， 更 可 能 抢占 资源 ， 当 然 ， 这 只 是 一 个 概率 问题 。 如 果 运 气 
不 好 ， 高 优先 级 线程 可 能 也 会 抢 扣 失败。 由 于 线程 的 优先 级 调度 和 底层 
操作 系统 有 密切 的 关系 ， 在 各 个 平台 上 表现 不 一 ， 并 且 这 种 优先 级 产生 
的 后 果 也 可 能 不 容易 预测 ， 无 法 精准 控制 ， 比 如 一 个 低 优 先 级 的 线程 可 
能 一 直 抢 占 不 到 资源 ， 从 而 始终 无 法 运行 ， 而 产生 饥饿 (虽然 优先 级 
低 ， 但 是 也 不 能 饿 死 它 呀 ) 。 因 此 ， 在 要 求 严格 的 场合 ， 还 是 需要 自己 
在 应 用 层 解决 线程 调度 问题 。 











在 Java 中 ， 使 用 1 到 10 表 示 线 程 优先 级 。 一 般 可 以 使 用 内 置 的 三 个 
静态 标量 表示 : 


public final static int MIN_PRIORITY = 1; 
public final static int NORM_PRIORITY = 5; 


public final static int MAX_PRIORITY = 10; 


数字 越 大 则 优先 级 越 高 ， 但 有 效 范围 在 1 到 10 之 间 。 下 面 的 代码 展 
示 了 优先 级 的 作用 。 高 优先 级 的 线程 倾 问 于 更 快 地 完成 。 


01 public class PriorityDemo { 


02 public static class HightPriority extends Thread{ 
03 static int count=0; 
04 public void run(){ 


05 while(true){ 


06 
07 
08 
09 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 
32 


synchronized(PriorityDemo.class)t{ 
count++; 
if (count >10000000) { 
System.out.printin("HightPriority is c 


break; 


} 


public static class LowPriority extends Thread{ 
static int count=0; 
public void run(){ 
while(true) { 
synchronized(PriorityDemo.class) { 
count++; 
if (count >10000000) { 
System.out.printin("LowPriority is com 


break; 


public static void main(String[] args) throws InterruptedE 


Thread high=new HightPriority(); 


33 LowPriority low=new LowPriority(); 


34 high.setPriority(Thread.MAX_PRIORITY) ; 
35 low.setPriority(Thread.MIN_PRIORITY) ; 
36 low.start(); 

37 high.start(); 

38 } 

39 } 


上 述 代码 定义 两 个 线程 ， 分 别 为 HightPriority 设 置 为 高 优先 级 ， 
LowPriority 为 低 优先 级 。 让 它们 完成 相同 的 工作 ， 也 就 是 把 count 从 0 加 
到 10000000。 完 成 后 ， 打 印信 息 给 一 个 提示 ， 这 样 我 们 就 知道 谁 先 完成 
工作 了 。 这 里 要 注意 ， 在 对 count 累 加 前 ， 我 们 使 用 synchronized 产 生 了 
一 次 资源 竞争 。 目 的 是 使 得 优先 级 的 差异 表现 得 更 为 明显 。 











大 家 可 以 尝试 执行 上 述 代码 ， 可 以 看 到 ， 蜗 优先 级 的 线程 在 大 部 分 
情况 下 ， 都 会 首先 完成 任务 〈 就 这 段 代码 而 言 ， 试 运行 多 次 ， 
HightPriority 总 是 比 LowPriority 快 ， 但 这 不 能 保证 在 所 有 情况 下 ， 一 定 
都 是 这 样 ) 。 


2.7 ”线程 安全 的 概念 上 


synchronized 





并 行程 序 开发 的 一 大 关注 重点 就 是 线程 安全 。 一 般 来 说 ， 程 序 并 行 
化 是 为 了 获得 更 高 的 执行 效率 ， 但 前 提 是 ， 高 效率 不 能 以 牺牲 正确 性 为 
代价 。 如 果 程 序 并 行 化 后 ， 连 基本 的 执行 结果 的 正确 性 都 无 法 保证 ， 那 
么 并 行程 序 本 身 也 就 没有 任何 意义 了 。 因 此 ， 线 程 安全 就 是 并 行程 序 的 
根本 和 根基 。 大 家 还 记得 那个 多 线程 读 写 long 型 数据 的 案例 吧 ! CE 
一 个 典型 的 反例 。 但 在 使 用 volatile 关 键 字 后 ， 这 种 错误 的 情况 有 所 改 
善 。 但 是 ，volatile 并 不 能 真正 的 保证 线程 安全 。 它 只 能 确保 一 个 线程 修 
改 了 数据 后 ， 其 他 线程 能 够 看 到 这 个 改动 。 但 当 两 个 线程 同时 修改 某 一 
个 数据 时 ， 却 依然 会 产生 冲突 。 























下 面 的 代码 演示 了 一 个 计数 器 ， 两 个 线程 同时 对 i 进行 累加 操作 ， 
各 执行 10000000 次 。 我 们 希望 的 执行 结果 当然 是 最 终 i 的 值 可 以 达到 
20000000， 但 事实 并 非 总 是 如 此 。 如 果 你 多 执行 几 次 下 述 代 码 ， 你 会 发 
现 ， 在 很 多 时 候 ，i 的 最 终 值 会 小 于 20000000。 这 就 是 因为 两 个 线程 同 
时 对 ij 进 行 写 入 时 ， 其 中 一 个 线程 的 结果 会 覆盖 另外 一 个 《虽然 这 个 时 
候 i 被 声明 为 volatile 变 量 ) 。 

















01 public class AccountingVol implements Runnable{ 


02 static AccountingVol instance=new AccountingVol(); 
03 static volatile int i=0; 
04 public static void increase(){ 


05 并 二 十 


06 } 


07 @Override 

08 public void run() { 

09 for(int j=0;j<10000000;j++){ 
10 increase(); 

11 } 

12 } 

13 public static void main(String[] args) throws InterruptedE 
14 Thread ti=new Thread(instance); 
15 Thread t2=new Thread(instance); 
16 ti.start();t2.start(); 

17 t1.join();t2.join(); 

18 System.out.println(i); 

19 } 

20 } 


图 2.8 展 示 了 这 种 可 能 的 冲突 ， 如 果 在 代码 中 发 生 了 类 似 的 情况 ， 
这 就 是 多 线程 不 安全 的 恶果 。 线 程 1 和 线程 2 同时 读 取 i 为 0， 并 各 自 计算 
得 到 i=1， 并 先后 写 入 这 个 结果 ， 因 此 ， 虽 和 然 i++ 被 执行 了 2 次 ， 但 是 实 
际 i 的 值 只 增加 了 1。 


图 2.8 多 线程 的 写 入 冲突 


要 从 根本 上 解决 这 个 问题 ， 我 们 就 必须 保证 多 个 线程 在 对 i 进行 操 
作 时 完全 同步 。 也 就 是 说 ， 当 线程 A 在 写 入 时 ， 线 程 B 不 仅 不 能 写 ， 同 
时 也 不 能 读 。 因 为 在 线程 A 写 完 之 前 ， 线 程 B 读 取 的 一 定 是 一 个 过 期 数 
据 。Java 中 ， 提 供 了 一 个 重要 的 关键 字 synchronized 来 实现 这 个 功能 。 











关键 字 synchronized 的 作用 是 实现 线程 间 的 同步 。 它 的 工作 是 对 同 
步 的 代码 加 锁 ， 使 得 每 一 次 ， 只 能 有 一 个 线程 进入 同步 块 ， 从 而 保证 线 
程 间 的 安全 性 《也 就 是 说 在 上 述 代 码 的 第 5 行 ， 每 次 应 该 只 有 一 个 线程 
可 以 执行 ) 。 





关键 字 synchronized 可 以 有 多 种 用 法 。 这 里 做 一 个 简单 的 整理 。 


ho 


o 指定 加 锁 对 象 : 对 给 定 对 象 加 锁 ， 进 入 同步 代码 前 要 获得 给 定 
象 的 锁 。 

。 直接 作用 于 实例 方法 : 相当 于 对 当前 实例 加 锁 ， 进 入 同步 代码 前 
要 获得 当前 实例 的 锁 。 

。 直接 作用 于 静态 方法 : 相当 于 对 当前 类 加 锁 ， 进 入 同步 代码 前 要 
获得 当前 类 的 锁 。 





下 述 代码 ， 将 Synchronized 作 用 于 一 个 给 定 对 象 instance， 因 此 ， 
次 当 线 程 进入 被 synchronized 包 于 的 代码 段 ， 束 都 会 要 求 请求 instance 实 
例 的 锁 。 如 果 当 前 有 其 他 线程 正 持 有 这 把 锁 ， 那 么 新 到 的 线程 就 必须 等 
待 。 这 样 ， 就 保证 了 每 次 只 能 有 一 个 线程 执行 t+ 操作 。 


public class AccountingSync implements Runnable{ 
static AccountingSync instance=new AccountingSync(); 
static int i=0; 


@Override 


public void run() { 
for(int j=0;j<10000000; j++){ 
synchronized(instance) { 


Iara 


I 


} 
//main rh AE DLA BARA 


当然 ， 上 述 代码 也 可 以 写成 如 下 形式 ， 两 者 是 等 价 的 : 


01 public class AccountingSync2 implements Runnable{ 


02 
03 
04 
05 
06 
07 
08 
09 
10 
11 
12 
13 
14 
15 
16 


static AccountingSync2 instance=new AccountingSync2(); 
static int i=0; 
public synchronized void increase(){ 

ett, 


t 


@Override 
public void run() { 
for(int j=0; j]<10000000; j++) { 


increase(); 


i 


public static void main(String[] args) throws InterruptedE 
Thread ti=new Thread(instance); 
Thread t2=new Thread(instance) ; 


ti.start();t2.start(); 


17 t1.join();t2.join(); 


18 System.out.println(i); 


上 上述 代码 中 ，synchronized 关 键 字 作用 于 一 个 实例 方法 。 这 残 是 说 
在 进入 increase() 方 法 前 ， 线 程 必须 获得 当前 对 象 实例 的 锁 。 在 本 例 中 就 
是 instance 对 象 。 在 这 里 ， 我 不 大 其 烦 地 再 次 给 出 main 函 数 的 实现 ， 是 
希望 强调 第 14、15 行 代码 ， 也 束 是 Thread 的 创建 方式 。 这 里 使 用 
Runnable 接 口 创建 两 个 线程 ， 并 且 这 两 个 线程 都 指 癌 同一 个 Runnable 接 
口 实例 〈instance 对 象 ) ， 这 样 才能 保证 两 个 线程 在 工作 时 ， 能 够 关注 
到 同一 个 对 象 锁 上 去 ， 从 而 保证 线程 安全 。 








一 种 错误 的 同步 方式 如 下 : 


01 public class AccountingSyncBad implements Runnable{ 


02 static int i=0; 

03 public synchronized void increase(){ 
04 IPE 

05 } 

06 @Override 

07 public void run() { 

08 for(int j=0;j<10000000;j++){ 

09 increase(); 

10 } 

11 } 

12 public static void main(String[] args) throws InterruptedE 


13 Thread ti=new Thread(new AccountingSyncBad()); 


14 Thread t2=new Thread(new AccountingSyncBad()); 


15 t1.start();t2.start(); 
16 t1.join();t2.join(); 
17 System.out.println(1); 
18 } 

19 } 


上 述 代 码 就 犯 了 一 个 严重 的 错误 。 虽 然 在 第 3 行 的 pcrease() 方 法 
中 ， 申 明 这 是 一 个 同步 方法 。 但 很 不 笠 的 是 ， 执 行 这 段 代 人 码 的 两 个 线程 
都 指 癌 了 不 同 的 Runnable 实 例 。 由 第 13、14 行 可 以 看 到 ， 这 两 个 线程 的 
Runnable 实 例 并 不 是 同一 个 对 象 。 因 此 ， 线 程 t1 会 在 进入 同步 方法 前 加 
锁 上 自己 的 Runnable 实 例 ， 而 线程 2 也 关注 于 目 己 的 对 象 锁 。 换 言 之 ， 这 
两 个 线程 使 用 的 是 两 把 不 同 的 锁 。 因 此 ， 线 程 安全 是 无 法 保证 的 。 


但 我 们 只 要 简单 地 修改 上 述 人 代码， 就 能 使 其 正确 执行 。 那 就 是 使 用 
synchronized 的 第 三 种 用 法 ， 将 其 作用 于 静态 方法 。 将 increase() 方 法 修 
改 如 下 : 


public static synchronized void increase(){ 


TEE. 


了 


Ww 


这 样 ， 即 使 两 个 线程 指向 不 同 的 Runnable 对 象 ， 但 由 于 方法 块 需 要 
请 求 的 是 当前 类 的 锁 ， 而 非 当 前 实例 ， 因 此 ， 线 程 间 还 是 可 以 正确 同 








= 





除了 用 于 线程 同步 、 确 保 线程 安全 外 ，synchronized 还 可 以 保证 线 
程 则 的 可 见 性 和 有 序 性 。 从 可 见 性 的 角度 上 讲 ，synchronized 可 以 完全 


蔡 代 volatile 的 功能 ， 只 是 使 用 上 没有 那么 方便 。 就 有 序 性 而 言 ， 由 于 

synchronized 限 制 每 次 只 有 一 个 线程 可 以 访问 同步 块 ， 因 此 ， 无 论 同步 

块 内 的 代码 如 何 被 乱 序 执行 ， 只 要 保证 串 行 语义 一 致 ， 那 么 执行 结果 总 
是 一 样 的 。 而 其 他 访问 线程 ， 又 必须 在 获得 锁 后 方 能 进入 代码 块 读 取 数 
据 ， 因 此 ， 它 们 看 到 的 最 终结 果 并 不 取决 于 代码 的 执行 过 程 ， 从 而 有 序 
性 问题 目 然 得 到 了 解决 (换言之 ， 被 synchronized 限 制 的 多 个 线程 是 串 

行 执行 的 〉。 





2.8 程序 中 的 幽灵 : 隐 珊 的 错误 


作为 一 名 软件 开 太 人 员 ， 修 复 程序 BUG 应 该 说 是 基本 的 日 第 工作 之 
一 。 作 为 Java 程 厅 员 ， 也 许 你 经 常会 被 抛 出 的 一 大 堆 的 异常 堆栈 所 困 
扰 ， 因 为 这 可 能 预示 着 你 又 有 工作 可 做 了 。 但 我 这 里 想 说 的 是 ， 如 果 程 
序 出 错 ， 你 看 到 了 异常 堆栈 ， 那 你 应 该 感到 格外 的 高 兴 ， 因 为 这 也 意味 
大 你 极 有 可 能 可 以 在 两 分 钟 内 修复 这 个 问题 (当然 ， 并 不 是 所 有 的 寞 营 
都 是 错误 ) 。 最 可 怕 的 情况 是 ， 系统 没有 任何 异常 表现 ， 没 有 日 志 ， 也 
没有 堆栈 ,但 是 却 给 出 了 一 个 错误 的 执行 结果 ， 这 种 情况 下 ， 才 真 会 让 
你 抓 狂 。 


2.8.1 无 提示 的 错误 案例 


我 在 这 里 想 给 出 一 个 系统 运行 错误 ， 却 没有 任何 提示 的 案例 。 让 大 
家 体会 一 下 这 种 情况 的 可 怕 之 处 。 我 相信 ， 在 任何 一 个 业务 系统 中 ， 求 
平均 值 ， 应 该 是 一 种 极其 常见 的 操作 。 这 里 就 以 求 两 个 整数 的 平均 值 为 
例 。 请 看 下 面 代码 : 

















int v1i=1073741827; 
int v2=1431655768; 
System.out.printin("vi="+v1); 
System.out.printin("v2="+v2); 
int ave=(vitv2)/2; 


System.out.printin("ave="+ave) ; 


上 述 代码 中 ， 加 粗 部 分 试图 计算 v1L 和 v2 的 均值 。 乍 看 之 下 ， 没 有 什 
么 问题 。 目 测 v1 和 v2 的 当前 值 ， 估 计 两 者 的 平均 值 大 约 在 12 亿 左右 。 但 
如 果 你 执行 代码 ， 却 会 得 到 以 下 输出 : 


V1=1073741827 
V2=1431655768 
ave=-894784850 








乍 看 之 下 ， 你 一 定 会 觉得 非常 吃惊 ， 为 什么 均值 竟然 反而 是 一 个 负 
数 。 但 只 要 你 有 一 点 研发 精神 ， 束 会 马上 有 所 和 觉悟。 这 和 古 一 个 典型 的 游 
出 问题 ! 显然 ，Vl+v2 的 结果 就 已 经 导致 int 的 游 出。 


把 这 个 问题 单独 拿 出 来 研究 ， 也 许 你 不 会 有 特别 的 感触 ， 但 是 ， 一 
旦 这 个 问题 发 生 在 一 个 复杂 系统 的 内 部 。 由 于 复杂 的 业务 逻辑 ， 很 可 能 
掩盖 这 个 看 起 来 微不足道 的 问题 ， 再 加 上 程序 自始至终 没有 任何 日 志 或 
异常 ， 再 加 上 你 运气 不 是 太 好 的 话 ， 这 类 问题 不 让 你 耗 上 几 个 通宵 ， 疏 
怕 也 是 难 有 眉目 。 





所 以 ， 我 们 自然 会 恐惧 这 些 问 题 ， 我 们 也 希望 在 程序 异常 时 ， 能 够 
得 到 一 个 异常 或 者 相关 的 日 志 。 但 是 ， 非 常 不幸 的 是 ， 错 误 地 使 用 并 
行 ， 会 非常 容易 产生 这 类 问题 。 它 们 难 疯 踪影 ， 就 如 同 幽 灵 一 般 。 


2.8.2 ”并 及 下 的 ArrayList 


我 们 都 知道 ，ArrayList 是 一 个 线程 不 安全 的 容 姻 。 如 果 在 多 线程 中 
使 用 ArrayList， 可 能 会 导致 程序 出 错 。 那 究竟 可 能 引起 哪些 问题 呢 ? 试 
看 下 面 的 代码 : 


public class ArrayListMultiThread { 
static ArrayList<Integer> al = new ArrayList<Integer>(10); 
public static class AddThread implements Runnable { 
@Override 
public void run() { 
for (int i = 0; i < 1000000; i++) { 
al.add(i); 


public static void main(String[] args) throws InterruptedExce 
Thread ti=new Thread(new AddThread()); 
Thread t2=new Thread(new AddThread()); 
ti.start(); 
t2.start(); 
t1.join();t2.join(); 


System.out.println(al.size()); 


上 述 代码 中 ，tL 和 t2 两 个 线程 同时 向 一 个 ArrayList 容 器 中 添加 容 
器 。 他 们 各 添加 1000000 个 元 素 ， 因 此 我 们 期 望 最 后 可 以 有 2000000 个 元 
素 在 ArrayList 中 。 但 如 果 你 执行 这 段 代 码 ， 你 可 能 会 得 到 三 种 结 


第 一 ， 程 序 正常 结束 ，ArrayList 的 最 终 大 小 确实 2000000。 这 说 明 
即使 并 行程 序 有 问题 ， 也 未 必 会 每 次 都 表现 出 来 。 


i, REP vO a i 


Exception in thread "Thread-0" java.lang.ArrayIndexOutOfBoundsExc 
at java.util.ArrayList.add(ArrayList.java:441) 
at geym.conc.ch2.notsafe.ArrayListMultiThread$AddThread.run 
(ArrayListMultiThread.java:12) 
at java.lang.Thread.run(Thread. java: 724) 
1000015 





这 是 因为 ArrayList 在 扩容 过 程 中 ， 内 部 一 致 性 被 破坏 ， 但 由 于 没有 
锁 的 保护 ， 另 外 一 个 线程 访问 到 了 不 一 致 的 内 部 状态 ， 导 致 出 现 越界 问 


jel 


第 三 ， 出 现 了 一 个 非常 隐蔽 的 错误 ， 比 如 打印 如 下 值 作 为 ArrayList 
的 大 小 : 


1793758 

显然 ， 这 是 由 于 多 线程 访问 冲突 ， 使 得 保存 容器 大 小 的 变量 被 多 线 
程 不 正常 的 访问 ， 同 时 两 个 线程 也 同时 对 ArrayList 中 的 同一 个 位 置 进行 
赋值 导致 的 。 如 果 出 现 这 种 问题 ， 那 么 很 不 幸 ， 你 就 得 到 了 一 个 没有 错 
误 提示 的 错误 。 并 且 ， 他 们 未 必 是 可 以 复 现 的 。 


注意 : 改进 的 方法 很 简单 ， 使 用 线程 安全 的 Vector 代替 ArrayList 
即 可 。 


2.8.3 ”并 及 下 施 民 的 HashMap 





HashMap 同 样 不 是 线程 安全 的 。 当 你 使 用 多 线程 访问 HashMap 时 ， 
也 可 能 会 遇 到 意 想 不 到 的 错误 。 不 过 和 ArrayList 不 同 ，HashMap 的 问题 
似乎 更 加 诡异 。 





public class HashMapMultiThread { 


static Map<String,String> map = new HashMap=String,String>| 


public static class AddThread implements Runnable { 
int start=0; 
public AddThread(int start){ 
this.start=start; 
} 
@Override 
public void run() { 
for (int i = start; i < 100000; it=2) { 


map.put(Integer.toString(i), Integer.toBinaryStri 


public static void main(String[] args) throws InterruptedExce 
Thread ti=new Thread(new HashMapMultiThread.AddThread(0) ) 
Thread t2=new Thread(new HashMapMultiThread.AddThread(1) ) 
ti.start(); 
t2.start(); 


t1.join();t2.join(); 


System.out.printin(map.size()); 


上 述 代码 使 用 tL 和 也 2 两 个 线程 同时 对 HashMap 进 行 putO0 操 作 。 如 果 
一 切 正 常 ， 我 们 期 望 得 到 的 map.size0 就 是 100000。 但 实际 上 ， 你 可 能 会 
得 到 以 下 三 种 情况 〈 注 意 ， 这 里 使 用 JDK 7 进行 试验 ) : 








第 一 ， 程 序 正 常 结束 ， 并 且 结 果 也 是 符合 预期 的 。HashMap 的 大 小 
为 100000。 








第 二 ， 程 序 正常 结束 ， 但 结果 不 符合 预期 ， 而 是 一 个 小 于 100000 的 
数字 ， 比 如 98868。 

第 三 ， 程 序 永远 无 法 结束 。 

对 于 前 两 种 可 能 ， 和 ArrayList 的 情况 非常 类 似 ， 因 此 ， 也 不 必 过 多 
解释 。 而 对 于 第 三 种 情况 ， 如 果 是 第 一 次 看 到 ， 我 想 大 家 一 定 会 觉得 特 
别 惊讶 ， 因 为 看 似 非 常 正常 的 程序 ， 怎 么 可 能 就 结束 不 了 呢 ? 








JER: 请 读者 谨慎 尝试 以 上 代码 ， 由 于 这 段 代 码 很 可 能 占用 两 个 
CPU 核 ， 并 使 它们 的 CPU 占有 率 达 到 100%。 如 果 CPU 性 能 较 弱 ， 可 能 
导致 死机 。 请 先 保 存 资料 ， 再 进行 尝试 。 


打开 任务 管理 器 ， 你 们 会 发 现 ， 这 段 代码 占用 了 极 高 的 CPU， 最 有 
可 能 的 表示 是 占用 了 两 个 CPU 核 ， 并 使 得 这 两 个 核 的 CPU 使 用 率 达 到 
100%。 这 非常 类 似 死 循环 的 情况 。 


使 用 jstack 工 具 显示 程序 的 线程 信息 ， 如 下 所 示 。 其 中 jps 可 以 显示 
当前 系统 中 所 有 的 Java 进 程 。 而 jstack 可 以 打印 给 定 Java 进 程 的 内 部 线程 


及 其 堆栈 。 


C:\Users\geym >jps 
14240 HashMapMultiThread 
1192 Jps 


C:\Users\geym >jstack 14240 


我 们 会 很 容易 找到 我 们 的 由 、t 刀 和 main 线 程 : 


"Thread-1" prio=6 tid=0x00bb2800 nid=0x16e0 runnable [0x04baf000 ] 
java.lang.Thread.State: RUNNABLE 
at java.util.HashMap.put(HashMap. java: 498) 
at geym.conc.ch2.notsafe.HashMapMultiThread$AddThread.run 
(HashMapMultiThread. java: 26) 


at java.lang.Thread.run(Thread. java: 724) 


"Thread-0" prio=6 tid=0x00bb0000 nid=0x1668 runnable [0x04d7f000 | 
java.lang.Thread.State: RUNNABLE 
at java.util.HashMap.put(HashMap.java:498) 
at geym.conc.ch2.notsafe.HashMapMultiThread$AddThread.run 
(HashMapMultiThread. java: 26) 
at java.lang.Thread.run(Thread. java: 724) 
"main" prio=6 tid=0x00c0cc00 nid=0xi6ec in Object.wait() [0x0102f 
java.lang.Thread.State: WAITING (on object monitor) 
at java.lang.Object.wait(Native Method) 
- waiting on <0x24930280> (a java.lang.Thread) 
at java.lang. Thread. join(Thread.java:1260) 
- locked <0x24930280> (a java.lang. Thread) 


at java.lang.Thread.join(Thread.java:1334) 


at geym.conc.ch2.notsafe.HashMapMultiThread.main(HashMapM 


可 以 看 到 ， 主 线程 main 正 处 于 等 待 状态 ， 并 且 这 个 等 竺 是 由 于 
join0 方 法 引起 的 ， 符 合 我们 的 预期 。 而 由 和 世 两 个 线程 都 处 于 Runnable 
状态 ， 并 且 当 前 执行 语句 为 HashMap.put() 方 法 。 查 看 put0) 方 法 的 第 498 
行 代 码 ， 如 下 所 示 : 


498 for (Entry<KkK,V> e = table[i]; e != null; e = e.next) { 


499 Object k; 

500 if (e.hash == hash && ((k = e.key) == key || key.equals(k 
501 V oldValue = e.value; 

502 e.value = value; 

503 e.recordAccess(this); 

504 return oldValue; 

505 } 

506 } 


可 以 看 到 ， 当 前 这 两 个 线程 正在 壳 历 HashMap 的 内 部 数据 。 当 前 所 
处 循环 乍 看 之 下 是 一 个 迭代 通 历 ， 就 如 同 过 历 一 个 链表 一 样 。 但 在 此 时 
此 刻 ， 由 于 多 线程 的 冲突 ， 这 个 链表 的 结构 已 经 但 到 了 人 破坏， 链表 成 环 
T! 当 链 表 成 环 时 ， 上 述 的 达 代 束 等 同 于 一 个 死 循环 ， 如 图 2.9 所 示 ， 
展示 了 最 简单 的 一 种 环 状 结构 ，Key1 和 Key2 互 为 对 方 的 next 元 素 。 此 
时 ， 通 过 next 引 用 遇 历 ， 将 形成 死 循环 。 








图 2-9 成 环 的 链表 


这 个 死 循环 的 问题 ， 如 果 一 旦 发 生 ， 着 实 可 以 让 你 郁 间 一 把 。 本 章 
的 参考 资料 中 也 给 出 了 一 个 真实 的 案例 。 但 这 个 死 循环 的 问题 在 JDK 8 
中 已 经 不 存在 了 。 由 于 JDK 8 对 HashMap 的 内 部 实现 了 做 了 大 规模 的 调 
整 ， 因 此 规避 了 这 个 问题 。 但 即使 这 样 ， 贸 然 在 多 线程 环境 下 使 用 
HashMap 依 然 会 导致 内 部 数据 不 一 致 。 最 简单 的 解决 方案 束 是 使 用 
ConcurrentHashMap 代 蔡 HashMap。 





2.8.4 JZE Wael: 错误 的 加 人 锁 


在 进行 多 线程 同步 时 ， 加 锁 是 保证 线程 安全 的 重要 手段 之 一 。 但 加 
锁 也 必须 是 合理 的 ， 在 “线程 安全 的 概念 与 synchronized” 一 市 中 ， 我 已 
经 给 出 了 一 个 常见 的 错误 加 锁 的 案例 。 也 束 是 锁 的 不 正确 使 用 。 在 本 市 
中 ， 我 将 介绍 一 个 更 加 隐 星 的 错误 。 

现在 ， 假 设 我 们 需要 一 个 计数 器 ， 这 个 计数 器 会 被 多 个 线程 同时 访 
问 。 为 了 确保 数据 正确 性 ， 我 们 自然 会 需要 对 计数 器 加 锁 ， 因 此 ， 就 有 
了 以 下 代码 : 








01 public class BadLockonInteger implements Runnable{ 


02 public static Integer i=0; 


03 static BadLockOnInteger instance=new BadLockOnInteger(); 
04 @Override 

05 public void run() { 

06 for(int j=0; j]<10000000; j++) { 

07 synchronized(i){ 

08 IPTE 

09 } 

10 } 

11 } 

12 

13 public static void main(String[] args) throws InterruptedE 
14 Thread ti=new Thread(instance); 

15 Thread t2=new Thread(instance); 

16 ti.start();t2.start(); 

17 t1.join();t2.join(); 

18 System.out.println(i); 

19 } 

20 } 


上 述 代码 的 第 7 一 9 行 ， 为 了 保证 计数 器 ji 的 正确 性 ， 每 次 对 i 自 增 
前 ， 都 先 获 得 i 的 锁 ， 以 此 保证 是 线程 安全 的 。 从 逻辑 上 看 ， 这 似乎 并 
没有 什么 不 对 ， 所 以 ， 我 们 就 满怀 信心 地 尝试 运行 我 们 的 代码 。 如 果 一 
切 正 常 ， 这 段 代码 应 该 返回 20000000 (每 个 线程 各 累加 10000000 次 〉。 


但 结果 却 让 我 们 惊 采 了 ， 我 得 到 了 一 个 比 20000000 小 很 多 的 数字 ， 
比如 15992526。 这 说 明 什么 问题 呢 ? 一 定 是 这 段 程序 并 没有 真正 做 到 线 








程 安 全 ! 但 把 锁 加 在 变量 i 上 又 有 什么 问题 呢 ? 似乎 加 锁 的 逻辑 也 是 无 
懈 可 击 的 。 


要 解释 这 个 问题 ， 得 从 Integer 说 起 。 在 Java 中 ，Integer 属 于 不 变 对 
象 。 也 就 是 对 象 一 旦 被 创建 ， 就 不 可 能 被 修改 。 也 就 是 说 ， 如 果 你 有 一 
个 Integer 代 表 1， 那 么 它 就 永远 表示 1， 你 不 可 能 修改 Integer 的 值 ， 使 它 
为 2。 那 如 果 你 需要 2 怎么 办 呢 ? 也 很 简单 ， 新 建 一 个 Integer， 并 让 它 表 








示 2 即 可 。 


如 果 我 们 使 用 javap 反 编译 这 段 代码 的 run(0) 方 法 ， 我 们 可 以 看 到 : 


iconst_0 
istore 1 
goto 36 
getstatic 
dup 

astore 2 
monitorenter 
getstatic 
invokevirtual 
iconst_1 
iadd 
invokestatic 
putstatic 
aload_2 


monitorexit 


#20; 


#20; 
#32; 


#14; 


#20; 


//Field i:Ljava/lang/Integer ; 


//Field i:Ljava/lang/Integer ; 


//Method java/lang/Integer.intValue: ()I 


//Method java/lang/Integer.valueOf:(1I)L 


//Field i:Ljava/lang/Integer ; 





在 第 19 一 22 行 《对 字 节 码 来 说 ， 这 是 偶 移 量 ， 这 里 简称 为 行 ) ， 实 


际 上 使 用 了 Integer.valueOf() 方 法 新 建 了 一 个 新 的 Integer 对 象 ， 并 将 它 赋 
值 给 变量 i。 也 就 是 说 ，i++ 在 真实 执行 时 变 成 了 : 


i=Integer.valueOf(i.intValue()+1); 


进一步 查看 Integer.valueOf()， 我 们 可 以 看 到 : 


public static Integer valueOf(int i) { 
assert IntegerCache.high >= 127; 
if (i >= IntegerCache.low && i <= IntegerCache.high) 
return IntegerCache.cache[i + (-IntegerCache. low) ]; 


return new Integer(i); 


Integer.valueOf() 实 际 上 是 一 个 工厂 方法 ， 它 会 倾 回 于 返回 一 个 代表 
中 定数 值 的 Pteger 实 例 。 因 此 ，i++ 的 本 质 是 ， 创 建 一 个 新 的 Integer 对 
象 ， 并 将 它 的 引用 赋值 给 i。 


如 此 一 来 ， 我 们 就 可 以 明白 问题 所 在 了 ， 由 于 在 多 个 线程 间 ， 并 不 
一 定 能 够 看 到 同一 个 对 象 〈 因 为 对象 一 直 在 变 ) ， 因 此 ， 两 个 线程 每 
次 加 锁 可 能 都 加 在 了 不 同 的 对 象 实例 上 ， 从 而 导致 对 临界 区 代码 控制 出 


现 问题 。 





修正 这 个 问题 也 很 容易 ， 只 要 将 


synchronized(1) { 


BOA: 


synchronized(instance) { 


BI Ay 
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第 3 章 ”JDK 并 发 包 


为 了 更 好 地 支持 并 发 程序 ，JDK 内 部 提供 了 大 量 实用 的 API 和 框 
架 。 在 本 章 中 ， 将 主要 介绍 这 些 JDK 内 部 的 功能 ， 其 主要 分 为 三 大 部 





> 


首先 ， 将 介绍 有 关 同 步 控 制 的 工具 ， 之 前 介绍 的 synchronized 关 键 
字 就 是 一 种 同步 控制 手段 ， 在 这 里 ， 我 们 将 看 到 更 加 丰富 多 彩 的 多 线程 
控制 方法 。 


其 次 ， 将 详细 介绍 JDK 中 对 线程 池 的 文 持 ， 使 用 线程 池 ， 将 能 很 大 
程度 上 提高 线程 调度 的 性 能 。 

第 三 ， 我 将 癌 大 家 介绍 JDK 的 一 些 并 发 容 露 ， 这 些 容 圳 专 为 并 行 访 
问 所 设计 ， 绝 对 是 高 效 、 安 全 、 稳 定 的 实用 工具 。 








3.1 多 线程 的 团队 协作 : 同步 控制 


同步 控制 是 并 发 程序 必 不 可 少 的 重要 手段 。 之 前 介绍 的 
synchronized 关 键 字 就 是 一 种 最 简单 的 控制 方法 。 它 决定 了 一 个 线程 是 
否 可 以 访问 临界 区 资源 。 同 时 ，Object.wait() 和 Object.notify(0) 方 法 起 到 
了 线程 等 竺 和 通知 的 作用 。 这 些 工具 对 于 实现 复杂 的 多 线程 协作 起 到 了 
重要 的 作用 。 在 本 节 中 ， 我 们 首先 将 介绍 synchronized、Object.waitO0 和 
Object.notify0) 方 法 的 蔡 代 品 〈 或 者 说 是 增强 版 ) — EAM. 











3.1.1 synchronized 的 功能 扩展 : HLA 
A 


重 入 锁 可 以 完全 蔡 代 synchronized 关 键 字 。 在 JDK ”5.0 的 早期 版 本 
中 ， 重 入 锁 的 性 能 远 远 好 于 synchronized， 但 从 JDK 6.07748, JDKZE 
synchronized 上 做 了 大 量 的 优化 ， 使 得 两 者 的 性 能 差距 并 不 大 。 





重 入 锁 使 用 java.util.concurrent.locks.ReentrantLock 类 来 实现 。 下 面 
是 一 段 最 简单 的 重 入 锁 使 用 案例 : 


01 public class ReenterLock implements Runnable{ 


02 public static ReentrantLock lock=new ReentrantLock(); 
03 public static int i=0; 

04 @Override 

05 public void run() { 


06 for(int j=0;j<10000000;j++){ 


07 lock.lock(); 


08 try{ 

09 i++; 

10 }finally{ 

Beal lock.unlock(); 

da J 

13 } 

14 } 

15 public static void main(String[] args) throws InterruptedE 
16 ReenterLock tl=new ReenterLock(); 
17 Thread ti=new Thread(tl); 

18 Thread t2=new Thread(tl); 

19 t1.start();t2.start(); 

20 t1.join();t2.join(); 

21 System.out.println(1); 

22 } 

23 } 


上 述 代码 第 7 一 12 行 ， 使 用 重 入 锁 保护 临界 区 资源 i:， 确 保 多 线程 对 i 
操作 的 安全 性 。 从 这 段 代 码 可 以 看 到 ， 与 synchronized 相 比 ， 重 入 锁 有 
着 显示 的 操作 过 程 。 开 发 人 员 必 须 手 动 指 定 何 时 加 锁 ， 何 时 释放 锁 。 也 
正 因为 这 样 ， 重 入 锁 对 逻辑 控制 的 灵活 性 要 远 远 好 于 synchronized。 但 
值得 注意 的 是 ， 在 退出 临界 区 时 ， 必 须 记 得 释放 锁 〈 代 码 第 11 行 ) ， 人 否 
则 ， 其 他 线程 就 没有 机 会 再 访问 临界 区 了 。 





有 些 同学 可 能 会 对 重 入 锁 的 名 字 感 到 奇怪 。 锁 就 叫 锁 鹃 ， 为 什么 要 
加 上 “ 重 入 ”两 个 字 呢 ?从 类 的 命名 上 看 ，Re- Entrant-Lock 翻 译 成 重 入 锁 


也 是 非常 贴切 的 。 之 所 以 这 么 叫 ， 那 是 因为 这 种 锁 是 可 以 有 反复 进入 的 。 
当然 ， 这 里 的 反复 仅仅 局 限于 一 个 线程 。 上 述 代 码 的 第 7 一 12 行 ， 可 以 
写成 下 面 的 形式 : 





lock.lock(); 
lock.lock(); 
try{ 
a Saat 
}finally{ 
lock.unlock(); 


lock.unlock(); 


在 这 种 情况 下 ， 一 个 线程 连续 两 次 获得 同一 把 锁 。 这 是 允许 的 ! 如 
果 不 允 许 这 么 操作 ， 那 么 同一 个 线程 在 第 2 次 获得 锁 时 ， 将 会 和 自己 产 
生死 锁 。 程 序 就 会 “ 卡 死 "在 第 2 次 申请 锁 的 过 程 中 。 但 需要 注意 的 是 ， 
如 有 果 同 一 个 线程 多 次 获得 锁 ， 那 么 在 释放 锁 的 时 候 ， 也 必须 释放 相同 次 
数 。 如 果 释 放 锁 的 次 数 多 ， 那 么 会 得 到 一 个 
java.lang.IllegalMonitorStateException 异 常 ， 有 反之， 如果 释放 锁 的 次 数 少 
了 ， 那 么 相当 于 线程 还 持 有 这 个 锁 ， 因 此 ， 其 他 线程 也 无 法 进入 临界 
IX. 


除了 使 用 上 的 灵活 性 外 ， 重 入 锁 还 提供 了 一 些 高 级 功能 。 比 如 ， 重 
入 锁 可 以 提供 中 断 处 理 的 能 


e HE DEF Hal by. 


对 于 synchronized 来 说 ， 如 果 一 个 线程 在 等 竺 锁 ， 那 么 结果 只 有 两 


种 情况 ， 要 么 它 获 得 这 把 锁 继 续 执 行 ， 要 么 它 束 保持 等 每 。 而 使 用 重 入 
锁 ， 则 提供 另外 一 种 可 能 ， 那 融 是 线程 可 以 被 中 断 。 也 就 是 在 等 待 锁 的 
过 程 中 ， 程 序 可 以 根据 需要 取消 对 锁 的 请 求 。 有 些 时 候 ， 这 么 做 是 非常 
有 必要 的 。 比 如 ， 如 果 你 和 朋友 约 好 一 起 去 打球 ， 如 果 你 等 了 半 小 时 ， 
朋友 还 没有 a 到， 突然 接 到 一 个 电话 ， 说 由 于 突 发 情况 ， 不 能 如 约 了 。 那 
么 你 一 定 就 扫兴 地 打道 回 认 了 。 中 断 正式 提供 了 一 套 类 似 的 机 制 。 如 果 
一 个 线程 正在 等 待 锁 ， 那 么 它 依 然 可 以 收 到 一 个 通知 ， 被 告知 无 须 再 等 
待 ， 可 以 停止 工作 了 。 这 种 情况 对 于 处 理 死 锁 是 有 一 定 帮 助 的 。 





下 面 的 代码 产生 了 一 个 死 锁 ， 但 得 益 于 锁 中 断 ， 我 们 可 以 很 轻易 地 
解决 这 个 死 锁 。 


01 public class IntLock implements Runnable { 








02 public static ReentrantLock lock1 = new ReentrantLock(); 
03 public static ReentrantLock lock2 = new ReentrantLock()/; 
04 int lock; 

05 Te 

06 * 控制 加 锁 顺 序 ， 方 便 构 造 死 锁 

07 * @param lock 

08 we 

09 public IntLock(int lock) { 

10 this.lock = lock; 

11 } 

12 

13 @Override 

14 public void run() { 


15 try { 


16 
17 
18 
19 
20 
24 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 
32 
33 
34 
35 
36 
37 
38 
39 
40 
41 
42 


if (lock == 1) { 
locki.lockInterruptibly(); 
try{ 

Thread.sleep(500); 
}catch(InterruptedException e){} 
lock2.lockInterruptibly(); 

} else { 
lock2.lockInterruptibly(); 
try{ 

Thread.sleep(500); 
}catch(InterruptedException e){} 
lock1.lockInterruptibly(); 


} catch (InterruptedException e) { 
e.printStackTrace(); 
} finally { 
if (lock1.isHeldByCurrentThread()) 
lock1.unlock(); 
if (lock2.isHeldByCurrentThread()) 
lock2.unlock(); 


System.out.printin(Thread.currentThread().getId()+ 


public static void main(String[] args) throws InterruptedE 


IntLock ri = new IntLock(1); 


43 IntLock r2 = new IntLock(2); 


44 Thread t1 = new Thread(rt1); 
45 Thread t2 = new Thread(r2); 
46 ti.start();t2.start(); 

47 Thread.sleep(1000); 

48 // 中 断 其 中 一 个 线程 

49 t2.interrupt(); 

50 } 

Si $ 


线程 t1 和 t2 启 动 后 ，t1 先 占用 lock1， 再 占用 lock2; t2 先 占用 lock2， 
再 请 求 lock1。 因 此 ， 很 容易 形成 L 和 t2 之 间 的 相互 等 待 。 在 这 里 ， 对 锁 
的 请 求 ， 统 一 使 用 lockInterruptibly0 方 法 。 这 是 一 个 可 以 对 中 断 进 行 啊 
应 的 锁 申 请 动作 ， 即 在 等 竺 锁 的 过 程 中 ， 可 以 啊 应 中 断 。 


在 代码 第 47 行 ， 主 线程 main 处 于 休眠 ， 此 时 ， 这 两 个 线程 处 于 死 锁 
的 状态 ， 在 代码 第 49 行 ， 由 于 包 线 程 被 中 断 ， 故 t2 会 放弃 对 lock1 的 申 
请 ， 同 时 释放 已 获得 lock2。 这 个 操作 导致 tI 线程 可 以 顺利 得 到 ]ock2 而 
继续 执行 下 去 。 








执行 上 述 代 码 ， 将 输出 : 


Java.lang.InterruptedException 
at java.util.concurrent.locks.AbstractQueuedSynchronizer. 
doAcquireInterruptibly(AbstractQueuedSynchronizer.java:898) 
at java.util.concurrent.locks.AbstractQueuedSynchronizer. 
acquireInterruptibly(AbstractQueuedSynchronizer.java:1222) 


at java.util.concurrent.locks.ReentrantLock.lockInterruptibly 


(ReentrantLock. java:335) 
at geym.conc.ch3.synctrl.IntLock.run(IntLock.java:31) 
at java.lang.Thread.run(Thread. java: 745) 

:线程 退出 

:线程 退出 


œo © 


可 以 看 到 ， 中 断后 ， 两 个 线程 双双 退出 。 但 真正 完成 工作 的 只 有 
tL。 而 乌 线程 则 放弃 其 任务 直接 退出 ， 释 放 资 源 。 


。 锁 申请 等 待 限 时 


除了 等 待 外 部 通知 之 外 ， 要 避免 死 锁 还 有 为 外 一 种 方法 ， 那 束 是 限 
时 等 每 。 依 然 以 约 朋友 打球 为 例 ， 如 果 朋 友 述 述 不 来 ， 又 无 法 联系 到 
他 。 那 么 ， 在 等 待 1~~2 个 小 时 后 ， 我 想 大 部 分 人 都 会 扫兴 离 去 。 对 线程 
来 说 也 是 这 样 。 通 向 ， 我 们 无 法 判断 为 什么 一 个 线程 迟 迟 拿 不 到 锁 。 也 
许 是 因为 死 锁 了 ， 也 许 是 因为 产生 了 饥饿 。 但 如 条 给 定 一 个 等 待 时 间 ， 
证 线程 自动 放 径 ， 那 么 对 系统 来 说 是 有 意义 的 。 我 们 可 以 使 用 tryLockO) 
方法 进行 一 次 限时 的 等 符 。 


下 面 这 段 代 码 展示 了 限时 等 待 锁 的 使 用 。 


01 public class TimeLock implements Runnable{ 


02 public static ReentrantLock lock=new ReentrantLock(); 
03 @Override 

04 public void run() { 

05 try { 

06 if(lock.tryLock(5, TimeUnit.SECONDS)){ 


07 Thread.sleep(6000); 


08 selse{ 


09 System.out.printin("get lock failed"); 
10 } 

11 } catch (InterruptedException e) { 

12 e.printStackTrace(); 

13 }finally{if(lock.isHeldByCurrentThread()) lock.unlock( 
14 } 

15 public static void main(String[] args) { 

16 TimeLock tl=new TimeLock(); 

17 Thread ti=new Thread(tl); 

18 Thread t2=new Thread(tl); 

19 t1.start(); 

20 t2.start(); 

21 } 

22 } 


在 这 里 ，tryLock() 方 法 接收 两 个 参数 ， 一 个 表示 等 待 时 长 ， 男 外 一 
个 表示 计时 单位 。 这 里 的 单位 设置 为 秒 ， 时 长 为 5， 表 示 线 程 在 这 个 锁 
请 求 中 ， 最 多 等 待 5 秒 。 如 果 超 过 5 秒 还 没有 得 到 锁 ， 束 会 返回 false。 如 
果 成 功 获得 锁 ， 则 返回 true。 








在 本 例 中 ， 由 于 占用 锁 的 线程 会 持 有 锁 长 达 6 秒 ， 故 为 一 个 线程 无 
法 在 5 秒 的 等 待 时 间 内 获得 锁 ， 因 此 ， 请 求 锁 会 失败 。 


ReentrantLock.tryLock() 方 法 也 可 以 不 带 参 数 直 接 运行 。 在 这 种 情况 
下 ， 当 前 线程 会 尝试 获得 锁 ， 如 果 锁 并 未 被 其 他 线程 占用 ， 则 申请 锁 会 
成 功 ， 并 立即 返回 true。 如 果 锁 被 其 他 线程 占用 ， 则 当前 线程 不 会 进行 
等 待 ， 而 是 立即 返回 false。 这 种 模式 不 会 引起 线程 等 待 ， 因 此 也 不 会 产 





生死 锁 。 


下 面 演 示 了 这 种 使 用 方式 : 


01 public class TryLock implements Runnable { 


02 
03 
04 
05 
06 
07 
08 
09 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 


public static ReentrantLock lock1 = new ReentrantLock(); 
public static ReentrantLock lock2 = new ReentrantLock(); 


int lock; 


public TryLock(int lock) { 


this.lock = lock; 


@Override 
public void run() { 
if (lock == 1) { 
while (true) { 
if (lock1.tryLock()) { 
try { 


try { 
Thread.sleep(500); 


} catch (InterruptedException e) { 
} 
if (lock2.tryLock()) { 
try { 
System.out.println(Thread.curr 
.getId() + ":My Job do 
return; 


} finally { 


26 
27 
28 
29 
30 
31 
32 
33 
34 
35 
36 
37 
38 
39 
40 
41 
42 
43 
44 
45 
46 
47 
48 
49 
50 
51 
52 


lock2.unlock(); 


} 
} finally { 


lock1.unlock(); 


Í 
} else { 
while (true) { 
if (lock2.tryLock()) { 
try { 


try { 
Thread.sleep(500); 


} catch (InterruptedException e) { 


} 
if (locki.tryLock()) { 
try { 
System.out.println(Thread.curr 
.getId() + ":My Job do 
return; 
} finally { 
locki.unlock(); 
} 
} 
} finally { 


lock2.unlock(); 


54 J 

55 i 

56 } 

57 } 

58 

59 public static void main(String[] args) throws InterruptedE 
60 TryLock ri = new TryLock(1); 
61 TryLock r2 = new TryLock(2); 
62 Thread ti = new Thread(rt1); 
63 Thread t2 = new Thread(r2); 
64 t1i.start(); 

65 t2.start(); 

66 } 

67 } 


上 述 代 码 中 ， 采 用 了 非常 容易 死 锁 的 加 锁 顺 序 。 也 就 是 先 让 tL 获 得 
lock1， 再 让 tb 获得 lock2， 接 着 做 反 回 请 求 ， 让 ttL 申 请 lock2，t2 申 请 
lock1。 在 一 般 情况 下 ， 这 会 导致 tL 和 t2 相 互 等 待 ， 从 而 引起 死 锁 。 





但 是 使 用 tryLockO 后 ， 这 种 情况 就 大 大 改善 了 。 由 于 线程 不 会 傻 傻 
地 等 待 ， 而 是 不 停 地 和 尝试， 因此， 只 要 执行 足够 长 的 时 间 ， 线 程 总 是 会 
得 到 所 有 需要 的 资源 ， 从 而 正常 执行 〈 这 里 以 线程 同时 获得 lock1 和 
lock2 两 把 锁 ， 作 为 其 可 以 正 间 执行 的 条 件 ) 。 在 同时 获得 lock1 和 lock2 
后 ， 线 程 就 打印 出 标志 着 任务 完成 的 信息 “My Job done”. 


执行 上 述 代 码 ， 等 竺 一 会 儿 《 由 于 线程 中 包含 休眠 500 曼 秒 的 代 
码 ) 。 最 终 你 还 是 可 以 欣喜 地 看 到 程序 执行 完毕 ， 并 产生 如 下 输出 ， 表 


示 两 个 线程 双双 正常 执行 。 


9:My Job done 
8:My Job done 


FB 


在 大 多 数 情 况 下 ， 锁 的 申请 都 是 非 公 平 的 。 也 束 是 说 ， 线 程 1 首先 
请 求 了 锁 A， 接 着 线程 2 也 请 求 了 锁 A。 那 么 当 锁 A 可 用 时 ， 是 线程 1 可 以 
获得 锁 还 是 线程 2 可 以 获得 锁 呢 ? 这 是 不 一 定 的 。 系 统 只 是 会 从 这 个 锁 
的 等 待 队 列 中 随机 挑选 一 个 。 因 此 不 能 保证 其 公平 性 。 这 就 好 比 买 票 不 
排队 ， 大 家 都 乱 哄 哄 得 围 在 售票 窗口 前 ， 售 票 员 忙 得 焦头烂额 ， 也 顾 不 
及 谁 先 谁 后 ， 随 便 找 个 人 出 票 就 完事 了 。 而 公平 的 锁 ， 则 不 是 这 样 ， 它 
会 按照 时 间 的 先后 顺序 ， 保 证 先 到 者 先 得 ， 后 到 者 后 得 。 公 平 锁 的 一 大 
特点 是 : 它 不 会 产生 饥饿 现象 。 只 要 你 排队 ， 最 终 还 是 可 以 等 到 资源 
的 。 如 果 我 们 使 用 synchronized 关 键 字 进行 锁 控 制 ， 那 么 产生 的 锁 就 是 
非 公 平 的 。 而 重 入 锁 允 许 我 们 对 其 公平 性 进行 设置 。 它 有 一 个 如 下 的 构 
ii PA BL: 








public ReentrantLock(boolean fair) 








当 参 数 fair 为 true 时 ， 表 示 锁 是 公平 的 。 公 平 锁 看 起 来 很 优美 ， 但 是 
要 实现 公平 锁 必 然 要 求 系统 维护 一 个 有 序 队 列 ， 因 此 公平 锁 的 实现 成 本 
比较 高 ， 性 能 相对 也 非 党 低下， 因此， 默认 情况 下 ， 锁 是 非 公 平 的 。 如 
果 没 有 特别 的 需求 ， 也 不 需要 使 用 公平 锁 。 公 平 锁 和 非 公 平 锁 在 线程 调 
度 表 现 上 也 是 非常 不 一 样 的 。 下 面 的 代码 可 以 很 好 地 突出 公平 锁 的 特 
点 : 





01 public class FairLock implements Runnable { 


02 public static ReentrantLock fairLock = new ReentrantLock(t 


03 

04 @Override 

05 public void run() { 

06 while(true) { 

07 try{ 

08 fairLock.lock(); 

09 System.out.printin(Thread.currentThread().getName( 
10 }finally{ 

tic fairLock.unlock(); 

12 } 

13 } 

14 } 

15 

16 public static void main(String[] args) throws InterruptedE 
17 FairLock ri = new FairLock(); 

18 Thread ti=new Thread(ri, "Thread_ti"); 

19 Thread t2=new Thread(ri1i, "Thread_t2"); 

20 ti.start();t2.start(); 

21 } 

22 } 





上 述 代码 第 2 行 ， 指 定 锁 是 公平 的 。 接 着 ， 由 两 个 线程 (和 也 分 别 请 
求 这 把 锁 ， 并 且 在 得 到 锁 后 ， 进 行 一 个 控制 侣 的 输出 ， 表 示 上 自己 得 到 了 
锁 。 在 公平 锁 的 情况 下 ， 得 到 输出 通常 如 下 所 示 : 





Thread_t1 获得 锁 


Thread_t2 获得 锁 
Thread_t1 获得 锁 
Thread_t2 获得 锁 
Thread_t1 获得 锁 
Thread_t2 获得 锁 
Thread_t1 获得 锁 
Thread_t2 获得 锁 
Thread_t1 获得 锁 
由 于 代码 会 产生 大 量 输出 ， 这 


中 ， 很 明显 可 以 看 到 ， 


里 只 截取 部 分 进行 说 明 。 在 这 个 输出 





两 个 线程 基本 上 是 交 蔡 获得 锁 的 ， 几 平 不 会 发 生 


同一 个 线程 连续 多 次 获得 锁 的 可 能 ， 从 而 公平 性 也 得 到 了 保证 。 如 果 不 


AAP, AB 





出 : 

前 面 还 有 一 大 段 t1 连 
Thread_t1 获得 锁 
Thread_t1 获得 锁 
Thread_t1 获得 锁 
Thread_t1 获得 锁 
Thread_t2 获得 锁 
Thread_t2 获得 锁 
Thread_t2 获得 锁 
Thread_t2 获得 锁 
Thread_t2 获得 锁 


面 还 有 一 大 段 t2 连 续 


可 以 看 到 ， 





续 获 得 锁 的 输出 


实 获 得 锁 的 输出 


根据 系统 的 调度 ， 


么 情况 会 完全 不 一 样 ， 下 面 是 使 用 非 公平 锁 时 的 部 分 输 


一 个 线程 会 倾向 于 再 次 获取 已 经 持 有 








的 锁 ， 这 种 分 配方 式 是 高 效 的 ， 但 是 无 公平 性 可 言 。 


对 上 面 ReentrantLock 的 几 个 重要 方法 整理 如 下 。 


lock0: 获得 锁 ， 如 果 锁 已 经 被 占用 ， 则 等 待 。 
lockInterruptibly(): 获得 锁 ， 但 优先 啊 应 中 断 。 

tryLock(): 尝试 获得 锁 ， 如 果 成 功 ， 返 回 true， 失 败 返 回 false。 
该 方法 不 等 待 ， 立 即 返 回 。 

e tryLock(long time, TimeUnit unit): 在 给 定时 间 内 尝试 获得 锁 。 
e unlock(): 释放 锁 。 


就 重 入 锁 的 实现 来 看 ， 它 主要 集中 在 Java 层 面 。 在 重 入 锁 的 实现 


中 ， 主 要 包含 三 个 要 素 : 





第 一 ， 是 原子 状态 。 原 子 状态 使 用 CAS 操 作 (在 第 4 章 进 行 详细 讨 
论 ) 来 存储 当前 锁 的 状态 ， 判 断 锁 是 否 已 经 被 别 的 线程 持 有 。 
第 二 ， 征 等 竺 队列 。 所 有 没有 请 求 到 锁 的 线程 ， 会 进入 等 竺 队列 进 


行 等 待 。 待 有 线程 释放 锁 后 ， 系 统 就 能 从 等 待 队列 中 唤醒 一 个 线 
程 ， 继 续 工作 。 


第 三 ， 是 阻塞 原 语 park() 和 unpark()， 用 来 挂 起 和 恢复 线程 。 没 有 得 
到 锁 的 线程 将 会 被 挂 起 。 有 关 park() 和 unpark() 的 详细 介绍 ， 可 以 参 
考 3.1.7 线 程 阻塞 工具 类 : LockSupport。 


3.1.2 重 入 锁 的 好 搭档 : Condition 条 
件 


如 果 大 家 理解 了 Object.wait0 和 Object.notify() 方 法 的 话 ， 那 么 就 能 
很 容易 地 理解 Condition 对 象 了 。 它 和 wait0 和 notify0) 方 法 的 作用 是 大 致 
相同 的 。 但 是 wait() 和 notify() 方 法 是 和 synchronized 关 键 字 合作 使 用 的 ， 
而 Condtion 是 与 重 入 锁 相关 联 的 。 通 过 Lock 接 口 ( 重 入 锁 就 实现 了 这 一 
接口 ) 的 Condition newCondition(0) 方 法 可 以 生成 一 个 与 当前 重 入 锁 绑 定 
的 Condition 实 例 。 利 用 Condition 对 象 ， 我 们 就 可 以 让 线程 在 合适 的 时 间 
等 待 ， 或 者 在 某 一 个 特定 的 时 刻 得 到 通知 ， 继 续 执行 。 


Condition 接 口 提 供 的 基本 方法 如 下 : 


void await() throws InterruptedException; 

void awaitUninterruptibly(); 

long awaitNanos(long nanosTimeout) throws InterruptedException; 
boolean await(long time, TimeUnit unit) throws InterruptedExcepti 
boolean awaitUntil(Date deadline) throws InterruptedException; 
void signal(); 


void signalAll(); 


以 上 方法 的 含义 如 下 : 


await() 方 法 会 使 当前 线程 等 待 ， 同 时 释放 当前 锁 ， 当 其 他 线程 中 
使 用 signal0) 或 者 signalAl0 方 法 时 ， 线 程 会 重新 获得 锁 并 继续 执 
行 。 或 者 当 线 程 被 中 断 时 ， 也 能 跳出 等 待 。 这 和 Object.wait(O) 方 
法 很 相似 。 

e awaitUninterruptibly() 方 法 与 await() 方 法 基本 相同 ， 但 是 它 并 不 会 
在 等 待 过 程 中 啊 应 中 断 。 

singal(0 方 法 用 于 唤醒 一 个 在 等 竺 中 的 线程 。 相 对 的 singalAl0 方 
法 会 唤醒 所 有 在 等 待 中 的 线程 。 这 和 Obejctnotify0) 方 法 很 类 似 。 








下 面 的 代码 简单 地 演示 了 Condition 的 功能 : 


01 public class ReenterLockCondition implements Runnable{ 


02 
03 
04 
05 
06 
07 
08 
09 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 


public static ReentrantLock lock=new ReentrantLock(); 
public static Condition condition = lock.newCondition(); 
@Override 
public void run() { 
try { 
lock.lock(); 
condition.await(); 
System.out.println("Thread is going on"); 
} catch (InterruptedException e) { 
e.printStackTrace(); 
}finally{ 
lock.unlock(); 


} 
public static void main(String[] args) throws InterruptedE 
ReenterLockCondition tl=new ReenterLockCondition(); 
Thread ti=new Thread(t1l); 
t1i.start(); 
Thread.sleep( 2000) ; 
// 通 知 线程 t1 继 续 执行 
lock.lock(); 
condition.signal(); 


lock.unlock(); 


26 } 


代码 第 3 行 ， 通 过 lock 生 成 一 个 与 之 绑 定 的 Condition 对 象 。 代 码 第 8 
行 ， 要 求 线 程 在 Condition 对 象 上 进行 等 待 。 代 码 第 23 行 ， 由 主线 程 main 
发 出 通知 ， 告 知 等 待 在 Condition 上 的 线程 可 以 继续 执行 了 。 


和 Object.wait() 和 notify() 方 法 一 样 ， 当 线程 使 用 Condition.await() 

时 ， 要 求 线 程 持 有 相关 的 重 入 锁 ， 在 Condition.awaitO0) 调 用 后 ， 这 个 线程 
会 释放 这 把 锁 。 同 理 ， 在 Condition.signal(0) 方 法 调用 时 ， 也 要 求 线 程 先 
获得 相关 的 锁 。 在 signal(0 方 法 调用 后 ， 系 统 会 从 当前 Condition 对 象 的 等 
待 队列 中 ， 唤 醒 一 个 线程 。 一 旦 线程 被 唤醒 ， 它 会 重新 答 试 获得 与 之 绑 
定 的 重 入 锁 ， 一 旦 成 功 获取 ， 就 可 以 继续 执行 了 。 因 此 ， 在 signal(0) 方 法 
调用 之 后 ， 一 般 需 要 释放 相关 的 锁 ， 谦 让 给 被 唤醒 的 线程 ， 让 它 可 以 继 
续 执 行 。 比 如 ， 在 本 例 中 ， 第 24 行 代码 就 释放 了 重 入 锁 ， 如 果 省 略 第 24 
行 ， 那 么 ， 虽 然 已 经 唤醒 了 线程 tt， 但 是 由 于 它 无 法 重新 获得 锁 ， 因 而 
也 就 无 法 真正 的 继续 执行 。 











在 JDK 内 部 ， 重 入 锁 和 Condition 对 象 被 广泛 地 使 用 ， 以 
ArrayBlockingQueue 为 例 〈 可 以 参阅 "3.3 IDKIF RA?) ， 它 的 
put() 方 法 实现 如 下 : 





// 在 ArrayBlockingQueue 中 的 一 些 定义 

private final ReentrantLock lock; 

private final Condition notEmpty; 

private final Condition notFull; 

lock = new ReentrantLock(fair); 

notEmpty = lock.newCondition(); // 生 成 一 个 与 1ock 绑 定 的 ( 


notFull = lock.newCondition(); 





//put() 方 法 的 实现 

public void put(E e) throws InterruptedException { 
if (e == null) throw new NullPointerException(); 
final E[] items = this.items; 


final ReentrantLock lock = this.lock; 





lock. lockInterruptibly(); // 对 put() 方 法 做 同步 
try { 
try { 
while (count == items.length) // 如 果 当 前 队列 已 满 
notFull.await(); // 等 待 队 列 有 足够 的 空间 





} catch (InterruptedException ie) { 
notFull.signal(); 
throw ie; 
} 
insert(e); //“notFull gan sin, v 
} finally { 
lock.unlock(); 


J 


private void insert(E x) { 
items[putIndex] = x; 
putIndex = inc(putIndex); 
++count; 


notEmpty.signal(); // 通 知 需要 take( ) 的 线程 ， 





同 理 ， 对 应 take0) 方 法 实现 如 下 : 


public E take() throws InterruptedException { 


final ReentrantLock lock = this.lock; 


lock. lockInterruptibly(); 


try { 
try { 
while (count == 0) 


notEmpty.await(); 


} catch (InterruptedException ie) 


notEmpty.signal(); 
throw ie; 
} 
E x = extract(); 
return x; 
} finally { 
lock.unlock(); 


} 


private E extract() { 
final E[] items = this.items; 
E x = items[takeIndex]; 
items[takeIndex] = null; 
takeIndex = inc(takeIndex); 
--count; 
notFull.signal()j; 


return x; 





// 对 take( ) 方 法 做 同步 


// 如 果 队 列 为 空 
// 则 消费 者 队列 要 等 待 一 个 





// 通 知 put ( ) 线 程 队 列 已 有 





3.1.3 ”人 允许 多 个 线程 同时 访问 : 信号 


= (Semaphore) 








信号 量 为 多 线程 协作 提供 了 更 为 强大 的 控制 方法 。 广 义 上 说 ， 信 和 号 
量 是 对 锁 的 扩展 。 无 论 是 内 部 锁 synchronized 还 是 重 入 锁 
ReentrantLock， 一 次 都 只 允许 一 个 线程 访问 一 个 资源 ， 而 信号 量 却 可 以 
虽 定 多 个 线程 ， 同 时 访问 某 一 个 资源 。 信 和 号 量 主 要 提供 了 以 下 构造 函 
数 : 








public Semaphore(int permits) 


public Semaphore(int permits, boolean fair) // 第 二 个 参数 可 以 指定 机 








在 构造 信号 量 对 象 时 ， 必 须要 指定 信号 量 的 准 入 数 ， 即 同时 能 申请 
多 少 个 许可 。 当 每 个 线程 每 次 只 申请 一 个 许可 时 ， 这 就 相当 于 指定 了 同 
时 有 多 少 个 线程 可 以 访问 某 一 个 资源 。 信 号 量 的 主要 逻辑 方法 有 





public void acquire() 

public void acquireUninterruptibly() 

public boolean tryAcquire() 

public boolean tryAcquire(long timeout, TimeUnit unit) 


public void release() 


acquire() 方 法 尝试 获得 一 个 准 入 的 许可 。 知 无 法 获得 ， 则 线程 会 等 
符 ， 直 到 有 线程 释放 一 个 许可 或 者 当前 线程 被 中 断 。 
acdquireUninterruptibly(0) 方 法 和 acquire(0) 方 法 类 似 ， 但 是 不 啊 应 中 断 。 





tryAcquire() 尝 试 获 得 一 个 许可 ， 如 果 成 功 返 回 true， 失 败 则 返回 false， 
它 不 会 进行 等 待 ， 立 即 返回 。release() 用 于 在 线程 访问 资源 结束 后 ， 释 
放 一 个 许可 ， 以 使 其 他 等 待 许可 的 线程 可 以 进行 资源 访问 。 


在 JDK 的 官方 Javadoc 中 ， 束 有 一 个 有 关 信 写 量 使 用 的 简单 实例 ， 有 


兴趣 的 读者 可 以 目 行 翻阅 ， 这 里 我 给 出 一 个 更 加 傻瓜 化 的 例子 : 


01 public class SemapDemo implements Runnable{ 


02 
03 
04 
05 
06 
07 
08 
09 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 


final Semaphore semp = new Semaphore(5); 
@Override 
public void run() { 
try { 
semp.acquire(); 
// 模 拟 耗 时 操作 
Thread.sleep(2000); 
System.out.printin(Thread.currentThread().getId()+ 
semp.release(); 
} catch (InterruptedException e) { 


e.printStackTrace(); 


public static void main(String[] args) { 
ExecutorService exec = Executors.newFixedtThreadPool (20 
final SemapDemo demo=new SemapDemo(); 
for(int 1=0;1<20;1i++){ 


exec .submit (demo); 


上 述 代 码 中 ， 第 7 一 9 行为 临界 区 管理 代码 ， 程 序 会 限制 执行 这 段 代 
码 的 线程 数 。 这 里 在 第 2 行 ， 申 明了 一 个 包含 5 个 许可 的 信号 量 。 这 就 意 
味 痢 同时 可 以 有 5 个 线程 进入 代码 段 第 7 一 9 行 。 申 请 信号 量 使 用 acquire0) 
操作 ， 在 离开 时 ， 务 必 使 用 release() 释 放 信号 量 〈 代 码 第 10 行 )。 这 就 
和 释放 锁 是 一 个 道理 。 如 果 不 注 发 生 了 信号 量 的 泄露 (申请 了 但 没有 释 
BO ， 那 么 可 以 进入 临界 区 的 线程 数量 就 会 越 来 越 少 ， 直 到 所 有 的 线程 
均 不 可 访问 。 在 本 例 中 ， 同 时 开启 20 个 线程 。 观 察 这 段 程 序 的 输出 ， 你 
就 会 发 现 系 统 以 5 个 线程 一 组 为 单位 ， 依 次 输出 带 有 线程 ID 的 提示 文 
本 。 














3.1.4 ReadWriteLocki 5 4ii 


ReadWriteLock 是 JDK5 中 提供 的 读 写 分 离 锁 。 读 写 分 离 锁 可 以 有 效 
地 帮助 减少 锁 竞 争 ， 以 提升 系统 性 能 。 用 锁 分 离 的 机 制 来 提升 性 能 非常 
容易 理解 ， 比 如 线程 AL1、A2、A3 进 行 写 操作 ，B1、B2、B3 进 行 读 操 
作 ， 如 果 使 用 重 入 锁 或 者 内 部 锁 ， 则 理论 上 说 所 有 读 之 间 、 读 与 写 之 
间 、 写 和 写 之 间 都 是 串 行 操作 。 当 B1 进 行 读 取 时 ，B2、B3 则 需要 等 待 
锁 。 由 于 读 操 作 并 不 对 数据 的 完整 性 造成 破坏 ， 这 种 等 竺 显然 是 不 合 
理 。 因 此 ， 读 写 锁 就 有 了 发 挥 功能 的 余地 。 





在 这 种 情况 下 ， 读 写 锁 允 许多 个 线程 同时 读 ， 使 得 B1、B2、B3 之 
间 真 正 并 行 。 但 是 ， 考 虑 到 数据 完整 性 ， 写 写 操作 和 读 写 操作 间 依 然 是 
需要 相互 等 竺 和 持 有 锁 的 。 总 的 来 说 ， 读 写 锁 的 访问 约束 如 表 3.1 所 





表 3. 1 读 写 锁 的 访问 约束 情况 





。 读 - 读 不 互 斥 ， 读 读 之 间 不 阻塞 。 
。 读 - 写 互 斥 ， 读 阻塞 写 ， 写 也 会 阻塞 读 。 





。 写 - 写 互 斥 ， 写 写 阻塞 。 





如 果 在 系统 中 ， 读 操作 次 数 远 远大 于 写 操 作 ， 则 读 写 锁 就 可 以 发 挥 
最 大 的 功效 ， 提 升 系统 的 性 能 。 这 里 我 给 出 一 个 稍微 付 张 点 的 案例 ， 来 
说 明 读 写 锁 对 性 能 的 帮助 。 








01 public class ReadwriteLockDemo { 
02 private static Lock lock=new ReentrantLock(); 
03 private static ReentrantReadwriteLock readwriteLock=new 


ReentrantReadwriteLock(); 


04 private static Lock readLock = readwriteLock.readLock(); 
05 private static Lock writeLock = readWriteLock.writeLock(); 
06 private int value; 

07 

08 public Object handleRead(Lock lock) throws InterruptedExce 
09 try{ 


10 lock.lock(); // 模 拟 读 操作 


11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 
32 
33 
34 
35 
36 
37 


// 


Thread.sleep(1000); // 读 操作 的 耗 时 越 多 ， 读 写 和 
return value; 

}finally{ 

lock.unlock(); 


i; 


public void handlewrite(Lock lock,int index) throws Interr 
try{ 
lock.lock(); // 模 拟 写 操 作 
Thread.sleep(1000) ) 
value=index; 
}finally{ 
lock.unlock(); 


} 


public static void main(String[] args) { 
final ReadwriteLockDemo demo=new ReadwriteLockDemo( ); 
Runnable readRunnale=new Runnable() { 
@Override 
public void run() { 
try { 
demo .handleRead(readLock); 
demo .handleRead( lock); 
} catch (InterruptedException e) { 


e.printStackTrace(); 


39 } 

40 yY; 

41 Runnable writeRunnale=new Runnable() { 

42 @Override 

43 public void run() { 

44 try { 

45 demo. handlewrite(writeLock, new Random().ne 
46 // demo. handlewrite(lock,new Random().nextI 
47 } catch (InterruptedException e) { 
48 e.printStackTrace(); 

49 } 

50 } 

51 }; 

52 

53 for(int i=0;i1<18;i++){ 

54 new Thread(readRunnale).start(); 

59 } 

56 

57 for(int i=18;i<20;i++){ 

58 new Thread(writeRunnale).start(); 

59 } 

60 } 

61 } 


上 述 代 码 中 ， 第 11 行 和 第 21 行 分 别 模拟 了 一 个 非常 耗 时 的 操作 ， 让 
线程 耗 时 1 秒 钟 。 它 们 分 别 对 应 读 耗 时 和 写 耗 时 。 人 代码 第 34 和 45 行 ， 分 


别 是 读 线程 和 写 线程 。 在 这 里 ， 第 34 行 使 用 读 锁 ， 第 35 行 使 用 写 锁 。 第 
53~55 行 开启 18 个 读 线 程 ， 第 57~59 行 ， 开 启 两 个 写 线程 。 由 于 这 里 使 
用 了 读 写 分 离 ， 因 此 ， 读 线程 完全 并 行 ， 而 写 会 阻塞 读 ， 因 此 ， 实 际 上 
这 段 代 码 运行 大 约 2 秒 多 就 能 结束 〈 写 线程 之 间 是 实际 串 行 的 ) 。 而 如 
果 使 用 第 35 行 代替 第 34 行 ， 使 用 第 46 行 代替 第 45 行 执行 上 述 代 码 ， 即 ， 
使 用 普通 的 重 入 锁 代 替 读 写 锁 。 那 么 所 有 的 读 和 写 线 程 之 间 都 必须 相互 
等 待 ， 因 此 整个 程序 的 执行 时 间 将 长 达 20 余 秒 。 

















3.1.5 ”倒计时 器 : CountDownLatch 


CountDownLatch 是 一 个 非常 实用 的 多 线程 控制 工具 类 。 “Count 
Down” 在 英文 中 意 为 倒 计 数 ，Latch 为 门 门 的 意思 。 如 果 翻 译 成 为 倒 计 数 
门 门 ， 我 想 大 家 都 会 觉得 不 知 所 云 吧 ! 因此 ， 这 里 简单 地 称 之 为 倒 计 数 
器 。 在 这 里 ， 门 六 的 含义 是 : 把 门 锁 起 来 ， 不 让 里 面 的 线程 跑 出 来 。 
此 ， 这 个 工具 通常 用 来 控制 线程 等 待 ， 它 可 以 让 某 一 个 线程 等 待 直到 倒 
计时 结束 ， 再 开始 执行 。 








对 于 倒计时 器 ， 一 种 典型 的 场景 就 是 火 和 发 映 。 在 火 和 发 射 前 ， 为 
了 保证 万 无 一 失 ， 往 往 还 要 进行 各 项 设备 、 仪 器 的 检查 。 只 有 等 所 有 的 
检查 完毕 后 ， 引 擎 才能 点 火 。 这 种 场景 就 非常 适合 使 用 
CountDownLatch。 它 可 以 使 得 点 火线 程 等 等 所 有 检查 线程 全 部 完工 后 ， 
再 执行 。 





CountDownLatch 的 构造 函数 接收 一 个 整数 作为 参数 ， 即 当前 这 个 计 
数 堪 的 计数 个 数 。 


public CountDownLatch(int count) 


下 面 这 个 简单 的 示例 ， 演 示 了 CountDownLatch 的 使 用 。 


01 public class CountDownLatchDemo implements Runnable { 


02 static final CountDownLatch end = new CountDownLatch(10); 
03 static final CountDownLatchDemo demo=new CountDownLatchDem 
04 @Override 

05 public void run() { 

06 try { 

07 // 模 拟 检查 任务 

08 Thread.sleep(new Random().nextInt(10)*1000) ; 

09 System.out.println("check complete"); 

10 end.countDown(); 

11 } catch (InterruptedException e) { 

12 e.printStackTrace(); 

13 } 

14 } 

15 public static void main(String[] args) throws InterruptedE 
16 ExecutorService exec = Executors.newFixedThreadPool(10 
17 for(int i=0;i1<10;i++){ 

18 exec . submit (demo); 

19 } 

20 // 等 待 检查 

21 end.await(); 

22 // 发 射 火 箭 

23 System.out.printlin("Fire!"); 

24 exec.shutdown(); 


25 } 


26 } 


上 述 代 码 第 2 行 ， 生 成 一 个 CountDownLatch 实 例 。 计 数 数量 为 10。 
这 表示 需要 有 10 个 线程 完成 任务 ， 等 竺 在 CountDownLatch 上 的 线程 才能 
继续 执行 。 代 码 第 10 行 ， 使 用 了 CountDownLatch.countdown0) 方 法 ， 也 
就 是 通知 CountDownLatch， 一 个 线程 已 经 完成 了 任务 ， 倒 计时 器 可 以 减 
1 啦 。 第 21 行 ， 使 用 CountDownLatch.await(0) 方 法 ， 要 求 主 线程 等 待 所 有 
10 个 检查 任务 全 部 完成 。 待 10 个 任务 全 部 完成 后 ， 主 线程 才能 继续 执 
行 。 


上 述 案 例 的 执行 逻辑 可 以 用 图 3.1 简 单 表示 。 


y g eee 
AAI IAH 


图 3. 1 CountDownLatch 示 意图 


主线 程 在 CountDownLatch 上 等 待 ， 当 所 有 检查 任务 全 部 完成 后 ， 主 
线程 方 能 继续 执行 。 


3.1.6 ”循环 栅栏 : CyclicBarrier 





CyclicBarrier 是 另外 一 种 多 线程 并 发 控制 实用 工具 。 和 


CountDownLatch 非 常 类 似 ， 它 也 可 以 实现 线程 间 的 计数 等 待 ， 但 它 的 功 
能 比 CountDownLatch 更 加 复杂 且 强 大 。 


CydlicBarrier 可 以 理解 为 循环 栅栏 。 栅 栏 就 是 一 种 障碍 物 ， 比 如 ， 
通常 在 私人 宅 氏 的 周围 就 可 以 围 上 一 圈 栅 栏 ， 阻 止 闲 杂 人 等 入 内 。 这 里 
当然 束 是 用 来 阻止 线程 继续 执行 ， 要 求 线程 在 栅栏 处 等 待 。 前 面 Cyclic 
意 为 循环 ， 也 就 是 说 这 个 计数 器 可 以 反复 使 用 。 比 如 ， 假 设 我 们 将 计数 
器 设置 为 10， 那 么 凑 齐 第 一 批 10 个 线程 后 ， 计 数 吉 就 会 归 零 ， 然 后 接 痢 
凌 齐 下 一 批 10 个 线程 ， 这 就 是 循环 栅栏 内 在 的 含义 。 








CydlicBarrier 的 使 用 场景 也 很 丰富 。 比 如 ， 司 令 下 达 命 令 ， 要 求 10 
个 士兵 一 起 去 完成 一 项 任务 。 这 时 ， 就 会 要 求 10 个 士兵 先 集合 报道 ， 接 
痢 ， 一 起 雄 超 直 气 昂昂 地 去 执行 任务 。 当 10 个 士兵 把 自己 手头 的 任务 都 
执行 完成 了 ， 那 么 司令 才能 对 外 宣布 ， 任 务 完成 ! 





比 CountDownLatch 了 略微 强大 一 些 ，CyclicBarrier 可 以 接收 一 个 参数 
作为 barrierAction。 所 请 barrierAction 就 是 当 计 数 旭 一 次 计数 完成 后 ， 系 
统 会 执行 的 动作 。 如 下 构造 函数 ， 其 中 ，parties 表 示 计 数 总 数 ， 也 就 是 
参与 的 线程 总 数 。 





public CyclicBarrier(int parties, Runnable barrierAction) 


下 面 的 示例 使 用 CyclicBarrier 演 示 了 上 述 司 令 命 令 士 兵 完 成 任务 的 
场景 。 


01 public class CyclicBarrierDemo { 
02 public static class Soldier implements Runnable { 
03 private String soldier; 


04 private final CyclicBarrier cyclic; 


05 
06 
07 
08 
09 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 


Soldier(CyclicBarrier cyclic, String soldierName) { 
this.cyclic = cyclic; 


this.soldier = soldierName; 


public void run() { 
try { 
// 等 待 所 有 士兵 到 齐 


cyclic.await(); 





doWork(); 
// 等 待 所 有 士兵 完成 工作 


cyclic.await(); 





} catch (InterruptedException e) { 
e.printStackTrace(); 
} catch (BrokenBarrierException e) { 


e.printStackTrace(); 


void dowork() { 
try { 
Thread.sleep(Math.abs(new Random().nextInt( )%1 
} catch (InterruptedException e) { 
e.printStackTrace(); 


t 


System.out.println(soldier +": 任 务 完成 "); 


32 
33 
34 
35 
36 
37 
38 
39 
40 
41 
42 
43 
44 
45 
46 
47 
48 
49 
50 
51 
52 
53 
54 
55 
56 
57 
58 


public static class BarrierRun implements Runnable { 
boolean flag; 
int N; 
public BarrierRun(boolean flag, int N) { 
this.flag = flag; 


this.N = N; 


public void run() { 
if (flag) { 
System.out.printlLn(" 司 令 :[ 士 兵 " + N + "个 ， 任 务 完 
} else { 
System.out ,println(" 司 令 :[ 士 兵 " +N + "个 ， 集 合 完 


flag = true; 


public static void main(String args[]) throws InterruptedE 
final int N = 10; 
Thread[] allSoldier=new Thread|[N]; 
boolean flag = false; 
CyclicBarrier cyclic = new CyclicBarrier(N, new Barrie 


// 设 置 屏障 点 ， 主 要 是 为 了 执行 这 个 方法 











59 System.out.printLn(" 集 合 队伍 ! "); 


60 for (ink i = 0P m < Ny st). E 

61 System.out.println(" 士 兵 "+i+" 报道 ! "); 

62 allSoldier[i]=new Thread(new Soldier(cyclic, "士兵 
63 allSoldier[i].start(); 

64 } 

65 } 

66 } 


上 述 代 码 第 57 行 ， 创 建 了 CyclicBarrier 实 例 ， 并 将 计数 器 设置 为 

10， 并 要 求 在 计数 器 达到 指标 时 ， 执 行 第 43 行 的 run0 方 法 。 每 一 个 士兵 
线程 会 执行 第 11 行 定义 的 run0) 方 法 。 在 第 14 行 ， 每 一 个 士兵 线程 都 会 等 
待 ， 直 到 所 有 的 士兵 都 集合 完毕 。 和 集合 完毕 后 ， 意 味 着 CyclicBarrier 的 
一 次 计数 完成 ， 当 再 一 次 调用 CyclicBarrier.awaitO0 时 ， 会 进行 下 一 次 计 
数 。 第 15 行 ， 模 拟 了 士兵 的 任务 。 当 一 个 士兵 任务 执行 完毕 后 ， 他 就 会 
要 求 CyclicBarrier 开 始 下 一 次 计数 ， 这 次 计数 主要 目的 是 监控 是 人 否 所 有 
的 士兵 都 已 经 完成 了 任务 。 一 旦 任务 全 部 完成 ， 第 35 行 定义 的 
BarrierRun 就 会 被 调用 ， 打 印 相 关 信 息 。 








上 述 代码 的 执行 输出 如 下 : 


集合 队伍 ! 

A O E 

// 篇 幅 有 限 ， 省 略 其 他 几 个 士兵 
anA 9 ue! 


AS: (£5104, RST! ] 
eee ON a 
// 篇 幅 有 限 ， 省 略 其 他 几 个 士兵 


士兵 4: 任 务 完成 
司令 : [士兵 10 个 ， 任 务 完 成 ! ] 





整个 工作 过 程 的 图 示 如 图 3.2 所 示 。 





FORA 
图 3. 2 ” CyclicBarrier 工 作 示 意图 


CydlicBarrier.await() 方 法 可 能 会 抛 出 两 个 异常 。 一 个 是 
InterruptedException， 也 就 是 在 等 竺 过程 中 ， 线 程 被 中 断 ， 应 该 说 这 是 
一 个 非常 通用 的 异常 。 大 部 分 迫使 线程 等 得 的 方法 都 可 能 会 抛 出 这 个 异 
常 ， 使 得 线程 在 等 待 时 依然 可 以 响应 外 部 紧急 事件 。 另 外 一 个 异常 则 是 
CyclicBarrier 特 有 的 BrokenBarrierException。 一 旦 过 到 这 个 异常 ， 则 表 
示 当 前 的 CydlicBarrier 已 经 破损 了 ， 可 能 系统 已 经 没有 办 法 等 待 所 有 线 
程 到 齐 了 。 如 果 继 续 等待 ， 可 能 就 是 徒劳 无 功 的 ， 因 此 ， 还 是 就 地 散 
货 ， 打 道 回 府 吧 ! 上 述 代码 第 18 一 22 行 处 理 了 这 2 种 异常 。 





如 朵 我 们 在 上 述 代 码 的 第 63 行 后 ， 插 入 以 下 代码 ， 使 得 第 5 个 士兵 
线程 产生 中 断 : 


Tf (1==5){ 
allSoldier[0].interrupt(); 


如 果 这 样 做 ， 我 们 很 可 能 就 会 得 到 1 个 InterruptedException 和 9 个 
BrokenBarrierException。 这 个 InterruptedException 就 是 被 中 断 线 程 抛 出 
的 。 而 其 他 9 个 BrokenBarrierException， 则 是 等 待 在 当前 CyclicBarrier 上 
的 线程 抛 出 的 。 这 个 异常 可 以 避免 其 他 9 个 线程 进行 永久 的 、 无 谓 的 等 
待 〈 因 为 其 中 一 个 线程 已 经 被 中 断 ， 等 竺 是 没有 结果 的 ) 。 





3.1.7 ”线程 阻塞 工具 类 : LockSupport 


LockSupport 是 一 个 非常 方便 实用 的 线程 阻塞 工具 ， 它 可 以 在 线程 
内 任意 位 置 让 线程 阻塞 。 和 Thread.suspend0 相 比 ， 它 弥补 了 由 于 
resume(O 在 前 发 生 ， 导 致 线程 无 法 继续 执行 的 情况 。 和 Object.waitO 相 
比 ， 它 不 需要 先 获 得 某 个 对 象 的 锁 ， 也 不 会 抛 出 InterruptedException 蜡 


Aw 


IN o 





LockSupport 的 静态 方法 parkO 可 以 阻塞 当前 线程 ， 类 似 的 还 有 
parkNanos()、parkUntil() 等 方法 。 它 们 实现 了 一 个 限时 的 等 待 。 


大 家 应 该 还 记得 ， 我 们 在 第 2 章 中 提 到 的 那个 有 关 suspend0 永 久 卡 
死 线程 的 例子 吧 ! 现在 ， 我 们 可 以 用 LockSupport 重 写 这 个 程序 : 


01 public class LockSupportDemo { 


02 public static Object u = new Object(); 

03 static ChangeObjectThread t1 = new ChangeObjectThread("t1i" 
04 static ChangeObjectThread t2 = new ChangeObjectThread("t2" 
05 

06 public static class ChangeObjectThread extends Thread { 


07 public ChangeObjectThread(String name){ 


08 super.setName(name) ; 


09 

10 @Override 

下 和 public void run() { 

12 synchronized (u) { 

13 System.out.println("in "+getName()); 
14 LockSupport.park(); 

15 Í 

16 } 

17 } 

18 

19 public static void main(String[] args) throws InterruptedE 
20 t1.start(); 

21 Thread.sleep(100); 

22 t2.start(); 

23 LockSupport.unpark(t1); 

24 LockSupport.unpark(t2); 

25 t1.join(); 

26 t2.join(); 

27 } 

28 } 


注意 ， 这 里 只 是 将 原来 的 suspend0 和 resume() 方 法 用 parkO0 和 
unpark(0) 方 法 做 了 蔡 换 。 当 然 ， 我 们 依然 无 法 保证 unpark(0) 方 法 发 生 在 
park0 方 法 之 后 。 但 是 执行 这 段 代 码 ， 你 会 发 现 ， 它 自始至终 都 可 以 正 
党 的 结束 ， 不 会 因为 park() 方 法 而 导致 线程 永久 性 的 挂 起 。 





这 是 因为 LockSupport 类 使 用 类 似 信号 量 的 机 制 。 它 为 每 一 个 线程 
准备 了 一 个 许可 ， 如 果 许 可 可 用 ， 那 么 park0 函 数 会 立即 返回 ， 并 且 消 
费 这 个 许可 (也 就 是 将 许可 变 为 不 可 用 〉 ， 如 果 许 可 不 可 用 ， 束 会 阻 
塞 。 而 unpark0) 则 使 得 一 个 许可 变 为 可 用 (但 是 和 信号 量 不 同 的 是 ， 许 
可 不 能 累加 ， 你 不 可 能 拥有 超过 一 个 许可 ， 它 永远 只 有 一 个 )。 














这 个 特点 使 得 : 即使 nparkO 操 作 发 生 在 park0 之 前 ， 它 也 可 以 使 下 
一 次 的 parkO 操 作 立 即 返 回 。 这 也 惑 是 上 述 代 码 可 顺利 结束 的 主要 原 
因 。 


同时 ， 处 于 parkO 挂 起 状态 的 线程 不 会 像 suspend0 那 样 还 给 出 一 个 
令 人 费解 的 Runnable 的 状态 。 它 会 非常 明确 地 给 出 一 个 WAITING 状 
态 ， 甚 至 还 会 标注 是 parkO 引 起 的 : 











"ti" #8 prio=5 os_prio=0 tid=0x00b1a400 nid=0x1994 waiting on con 
java.lang.Thread.State: WAITING (parking) 
at sun.misc.Unsafe.park(Native Method) 
at java.util.concurrent.locks.LockSupport.park(LockSuppor 
at geym.conc.ch3.1s.LockSupportDemo$ChangeObjectThread. ru 
- locked <0x048b2680> (a java.lang.Object) 


这 使 得 分 析 问 题 时 格外 方便 。 此 外 ， 如 果 你 使 用 park(Object) 函 数 ， 
还 可 以 为 当前 线程 设置 一 个 阻 暑 对 象 。 这 个 阻 器 对象 会 出 现在 线程 
Dump 中 。 这 样 在 分 析 问 题 时 ， 就 更 加 方便 了 。 


比如 ， 如 果 我 们 将 上 述 代码 第 14 行 的 park0 改 为 : 


LockSupport.park(this); 


么 在 线程 Dump 时 ， 你 可 能 会 看 到 如 下 信息 : 


"ti" #8 prio=5 os_prio=0 tid=0x0117ac00 nid=0x2034 waiting on con 
java.lang.Thread.State: WAITING (parking) 

at sun.misc.Unsafe.park(Native Method) 

- parking to wait for <0x048b4738> (a geym.conc.ch3.1s. 
Demo$ChangeObjectThread ) 

at java.util.concurrent.locks.LockSupport.park(LockSuppor 

at geym.conc.ch3.1s.LockSupportDemo$ChangeObjectThread.ru 
(LockSupportDemo. java:18) 

- locked <0x048b2808> (a java.lang.Object) 


注意 ， 在 堆栈 中 ， 我 们 甚至 还 看 到 了 当前 线程 等 待 的 对 象 ， 这 里 就 
是 ChangeObjectThread 实 例 。 


除了 有 定时 阻塞 的 功能 外 ，LockSupport.park0O 还 能 支持 中 断 影 响 。 
但 是 和 其 他 接收 中 断 的 函数 很 不 一 样 ，LockSupport.park0 不 会 抛 出 
InterruptedException 异 常 。 它 只 是 会 默默 的 返回 ， 但 是 我 们 可 以 从 
Thread.interrupted() 等 方法 获得 中 断 标 记 。 





01 public class LockSupportIntDemo { 


02 public static Object u = new Object(); 

03 static ChangeObjectThread t1 = new ChangeObjectThread( "ti" 
04 static ChangeObjectThread t2 = new ChangeObjectThread("t2" 
05 

06 public static class ChangeObjectThread extends Thread { 

07 public ChangeObjectThread(String name){ 


08 super . setName (name); 


09 $ 





10 @Override 

11 public void run() { 

12 synchronized (u) { 

13 System.out .printlLn("in "+getName()); 
14 LockSupport.park(); 

15 if(Thread.interrupted()){ 

16 System.out.printin(getName()+" 被 中 断 了 " ) ; 
17 } 

18 } 

19 System,out.printLn(getName()+" 执 行 结束 " ) ， 
20 } 

21 } 

22 

23 public static void main(String[] args) throws InterruptedE 
24 ti.start(); 

25 Thread.sleep(100) ; 

26 t2.start(); 

27 t1.interrupt(); 

28 LockSupport.unpark(t2); 

29 } 

30 } 


注意 上 述 代 码 在 第 27 行 ， 中 断 了 处 于 park0 状 态 的 tt。 之 后 ，tlL 可 以 
马上 啊 应 这 个 中 断 ， 并 且 返 回 。 之 后 在 外 面 等 待 的 2 才 可 以 进入 临界 
区 ， 并 最 终 由 LockSupport.unpark(t2) 操 作 使 其 运行 结束 。 


3.2 ”线程 复 用 : 线程 池 


多 线程 的 软件 设计 方法 确实 可 以 最 大 限度 地 发 挥 现代 多 核 处 理 占 的 
计算 能 力 ， 提 高 生产 系统 的 否 吐 量 和 性 能 。 但 是 ， 寿 不 加 控制 和 管理 的 
随意 使 用 线程 ， 对 系统 的 性 能 反而 会 产生 不 利 的 影响 。 


一 种 最 为 简单 的 线程 创建 和 回收 的 方法 类 似 如 下 代码 : 


new Thread(new Runnable(){ 
@Override 
public void run() { 
//do sth. 
} 
}).start(); 


以 上 代码 创建 了 一 个 线程 ， 并 在 run() 方 法 结束 后 ， 自 动 回收 该 线 
程 。 在 简单 的 应 用 系统 中 ， 这 段 代码 并 没有 太 多 问题 。 但 是 在 真实 的 生 
产 环境 中 ， 系 统 由 于 真实 环境 的 需要 ， 可 能 会 开局 很 多 线程 来 文 撑 其 应 
用 。 而 当 线程 数量 过 大 时 ， 反 而 会 耗 尽 CPU 和 和 内 存 资源 。 





首先 ， 虽 然 与 进程 相 比 ， 线 程 是 一 种 轻 量 级 的 工具 ， 但 其 创建 和 关 
闭 依然 需要 花费 时 间 ， 如 果 为 每 一 个 小 的 任务 都 创建 一 个 线程 ， 很 有 可 
能 出 现 创建 和 销毁 线程 所 占用 的 时 间 大 于 该 线程 真实 工作 所 消耗 的 时 间 
的 情况 ， 反 而 会 得 不 偿 失 。 


其 次 ， 线 程 本 映 也 是 要 占用 内 存 空间 的 ， 大 量 的 线程 会 抢占 宝贵 的 
内 存 资源 ， 如 果 处 理 不 当 ， 可 能 会 导致 Out of Memory 异 常 。 即 便 没 


有 ， 大 量 的 线程 回收 也 会 给 GC 带 来 很 大 的 压力 ， 延 长 GC 的 停顿 时 间 。 


因此 ， 对 线程 的 使 用 必须 掌握 一 个 度 ， 在 有 限 的 范围 内 ， 增 加 线程 
的 数量 可 以 明显 提高 系统 的 否 吐 量 ， 但 一 旦 超出 了 这 个 范围 ， 大 量 的 线 
程 只 会 拖 垮 应 用 系统 。 因 此 ， 在 生产 环境 中 使 用 线程 ， 必 须 对 其 加 以 控 
制 和 管理 。 














注意 : 在 实际 生产 环境 中 ， 线 程 的 数量 必须 得 到 控制 。 育 目的 大 量 
创建 线程 对 系统 性 能 是 有 伤害 的 。 


3.2.1 什么 是 线程 池 


为 了 避免 系统 频繁 地 创建 和 销毁 线程 ， 我 们 可 以 让 创建 的 线程 进行 
复 用 。 如 果 大 家 进行 过 数据 库 开 发 ， 对 数据 库 连 接 池 应 该 不 会 陌生 。 为 
了 避免 每 次 数据 库 查 询 都 重新 建立 和 销毁 数据 库 连 接 ， 我 们 可 以 使 用 数 
据 库 连 接 池 维 护 一 些 数 据 库 连接 ， 让 他 们 长 期 保持 在 一 个 激活 状态 。 当 
系统 需要 使 用 数据 库 时 ， 并 不 是 创建 一 个 新 的 连接 ， 而 是 从 连接 池 中 获 
得 一 个 可 用 的 连接 即 可 。 反 之 ， 当 需要 关闭 连接 时 ， 并 不 真 的 把 连接 关 
闭 ， 而 是 将 这 个 连接 * 还 ”给 连接 池 即 可 。 通 过 这 种 方式 ， 可 以 节约 不 少 
创建 和 销毁 对 象 的 时 间 。 





线程 池 也 是 类 似 的 概念 。 线 程 池 中 ， 总 有 那么 几 个 活跃 线程 。 当 你 
需要 使 用 线程 时 ， 可 以 从 池子 中 随便 拿 一 个 空闲 线程 ， 当 完成 工作 时 ， 
并 不 急 厦 关闭 线程 ， 而 是 将 这 个 线程 退回 到 池子 ， 方 便 其 他 人 使 用 。 





简 而 言 之 ， 在 使 用 线程 池 后 ， 创 建 线程 变 成 了 从 线程 池 获 得 空闲 线 
程 ， 关 闭 线程 变 成 了 回 池 子 归 还 线程 ， 如 图 3.3 所 示 。 
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图 3-3 ”线程 池 的 作用 


3.2.2 ABH RIS: JDK 对 线 
程 池 的 支持 


为 了 能 够 更 好 地 控制 多 线程 ，JDK 提 供 了 一 套 Executor 框 架 ， 帮 助 
开发 人 员 有 效 地 进行 线程 控制 ， 其 本 质 就 是 一 个 线程 池 。 它 的 核心 成 员 
如 图 3.4 所 示 。 
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以 上 成 员 均 在 java.util.concurrent 包 中 ， 是 JDK 并 发 包 的 核心 类 。 其 
中 ThreadPoolExecutor 表 示 一 个 线程 池 。Executors 类 则 扮演 着 线程 池 工 
三 的 角色 ， 通 过 Executors 可 以 取得 一 个 拥有 特定 功能 的 线程 池 。 从 
UML 图 中 亦 可 知 ，ThreadPoolExecutor 类 实现 了 Executor 接 口 ， 因 此 通过 
这 个 接口 ， 任 何 Runnable 的 对 象 都 可 以 被 ThreadPoolExecutor 线 程 池 调 


E. 


Executor 框 架 提供 了 各 种 类 型 的 线程 池 ， 主 要 有 以 下 工厂 方法 : 


public 
public 
public 
public 
public 


static 
static 
static 
static 


static 


ExecutorService newFixedThreadPool(int nThreads) 
ExecutorService newSingleThreadExecutor() 
ExecutorService newCachedThreadPool() 
ScheduledExecutorService newSingleThreadScheduledEx 


ScheduledExecutorService newScheduledThreadPool(int 


以 上 工 广 方法 分 别 返 回 具 有 不 同 工 作 特性 的 线程 池 。 这 些 线程 池 工 
三 方法 的 具体 说 明 如 下 。 


e hewFixedThreadPool0) 方 法 : 该 方法 返回 一 个 固定 线程 数量 的 线 
程 池 。 该 线程 池 中 的 线程 数量 始终 不 变 。 当 有 一 个 新 的 任务 提交 
时 ， 线 程 池 中 和 大 有 衬 朵 线程 ， 则 立即 执行 。 奋 没有 ， 则 新 的 任务 
会 被 暂 存 在 一 个 任务 队列 中 ， 待 有 线程 空间 时 ， 便 处 理 在 任务 队 
列 中 的 任务 。 

newSingleThreadExecutor() 方 法 : 该 方法 返回 一 个 只 有 一 个 线程 
的 线程 池 。 知 多 余 一 个 任务 被 提交 到 该 线程 池 ， 任 务 会 被 保存 在 
一 个 任务 队列 中 ， 竺 线程 空 亲 ， 按 先入 先 出 的 顺序 执行 队列 中 的 


任务 。 








e newCachedThreadPool0) 方 法 : 该 方法 返回 一 个 可 根据 实际 情况 调 





整 线程 数 量 的 线程 池 。 线 程 池 的 线程 数量 不 确定 ， 但 知 有 空闲 线 
程 可 以 复 用 ， 则 会 优先 使 用 可 复 用 的 线程 。 各 所 有 线程 均 在 工 
作 ， 叉 有 新 的 任务 提交 ， 则 会 创建 新 的 线程 处 理 任务 。 所 有 线程 
在 当前 任务 执行 完毕 后 ， 将 返回 线程 池 进 行 复 用 。 
newSingleThreadScheduledExecutor() 方 法 : 该 方法 返回 一 个 
ScheduledExecutorService 对 象 ， 线 程 池 大 小 为 1。 
ScheduledExecutorService 接 口 在 ExecutorService 接 口 之 上 扩展 了 
在 给 定时 间 执 行 某 任务 的 功能 ， 如 在 某 个 固定 的 延 时 之 后 执行 ， 
或 者 周期 性 执行 某 个 任务 。 

newScheduledThreadPool0) 方 法 : 该 方法 也 返回 一 个 
ScheduledFxecutorService 对 象 ， 但 该 线程 池 可 以 指定 线程 数量 。 








.固定 大 小 的 线程 池 


p= 


这 里 ， 我 们 以 newFixedThreadPool0) 为 例 ， 简 单 地 展示 线程 池 的 使 


public class ThreadPoolDemo { 
public static class MyTask implements Runnable { 

@Override 

public void run() { 
System.out.printiln(System.currentTimeMillis() + ": 

+ Thread.currentThread().getId()); 
try { 
Thread.sleep(1000); 

} catch (InterruptedException e) { 


e.printStackTrace(); 


13 } 

14 

15 public static void main(String[] args) { 

16 MyTask task = new MyTask(); 

17 ExecutorService es = Executors.newFixedThreadPool(5); 
18 Tor (aime i = Op a < O aa) e 

19 es.submit(task); 

20 } 

21 } 

22 } 


上 述 代 码 中 ， 第 17 行 创建 了 固定 大 小 的 线程 地 ， 内 有 5 个 线程 。 在 
第 19 行 ， 依 次 同 线 程 池 提 交 了 10 个 任务 。 此 后 ， 线 程 池 就 会 安排 调度 这 
10 个 任务 。 每 个 任务 都 会 将 目 己 的 执行 时 间 和 执行 这 个 线程 的 ID 打印 出 
来 ， 并 且 在 这 里 ， 安 排 每 个 任务 要 执行 1 秒 钟 。 


执行 上 述 代 码 ， 可 以 得 到 类 似 以 下 输出 : 


1426510293450:Thread ID:8 
1426510293450: Thread ID:9 
1426510293450: Thread ID:12 
1426510293450: Thread ID:10 
1426510293450: Thread ID:11 
1426510294450: Thread ID:12 
1426510294450: Thread ID:11 
1426510294450: Thread ID:8 
1426510294450: Thread ID:10 


1426510294450:Thread ID:9 





这 个 输出 束 表 示 这 10 个 线程 的 执行 情况 。 很 显然 ， 前 5 个 任务 和 后 5 
个 任务 的 执行 时 间 正 好 相差 1 秒 钟 〈 注 意 时 间 戳 的 单位 是 毫秒 ) ， 并 且 
前 5 个 任务 的 线程 ID 和 后 5 个 任务 也 是 完全 一 致 的 〈 都 是 gs、9、10、11、 
12) 。 这 说 明 在 这 10 个 任务 中 ， 是 分 成 2 批 次 执行 的 。 这 也 完全 符合 一 
个 只 有 5 个 线程 的 线程 池 的 行为 。 


有 兴趣 的 读者 可 以 将 其 改造 成 ewCachedThreadPool()， 看 看 任务 的 
分 配 情况 会 有 何 变 化 ? 


2. 计划 任务 





另外 一 个 值得 注意 的 方法 是 newScheduledThreadPool()。 它 返回 一 个 
ScheduledExecutorService 对 象 ， 可 以 根据 时 间 需 要 对 线程 进行 调度 。 它 
的 一 些 主要 方法 如 下 : 











public ScheduledFuture 和 ?> schedule(Runnable command, long delay, 
public ScheduledFuture<?> scheduleAtFixedRate(Runnable command, 
long initialDela 
long period, 
TimeUnit unit); 
public ScheduledFuture<?> schedulewithFixedDelay(Runnable comman 
long initialD 
long delay, 


TimeUnit unit 


与 其 他 几 个 线程 池 不 同 ，ScheduledExecutorService 并 不 一 定 会 立即 
安排 执行 任务 。 它 其 实 是 起 到 了 计划 任务 的 作用 。 它 会 在 指定 的 时 间 ， 





对 任务 进行 调度 。 如 果 大 家 使 用 过 Linux 下 的 crontab 工 具 应 该 就 能 很 容 
易 地 理解 它 了 。 





作为 说 明 ， 这 里 给 出 了 三 个 方法 。 方 法 schedule() 会 在 给 定时 间 ， 对 
任务 进行 一 次 调度 。 方 法 scheduleAtFixedRate() 和 
ScheduleWithFixedDelay0O 会 对 任务 进行 周期 性 的 调度 。 但 是 两 者 有 一 点 
小 小 的 区 别 ， 如 图 3.5 所 示 。 
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图 3.5 FixedRate 和 FixDelay 区 别 


对 于 FixedRate 方 式 来 说， 任务 调度 的 频率 是 一 定 的 。 它 是 以 上 一 个 
任务 开始 执行 时 间 为 起 点 ， 之 后 的 period 时 间 ， 调 度 下 一 次 任务 。 而 
FixDelay 则 是 在 上 一 个 任务 结束 后 ， 再 经 过 delay 时 间 进 行 任务 调度 。 





由 于 担心 我 的 解释 不 够 周全 ， 我 也 很 乐意 将 官方 文档 中 的 描述 贴 出 
来 供 大 家 参考 ， 从 而 可 以 更 精确 地 理解 两 者 的 差别 : 


e scheduleAtFixedRate 


o Creates and executes a periodic action that becomes enabled first 
after the given initial delay, and subsequently with the given 


period; that is executions will commence after initialDelay then 


initialDelay+period, then initialDelay + 2 * period, and so on. 

o 翻译 : 创建 一 个 周期 性 任务 。 任 务 开 始 于 给 定 的 初始 延 时 。 后 
续 的 任务 按照 给 定 的 周期 进行 : 后 续 第 一 个 任务 将 会 在 
initialDelay+period 时 执行 ， 后 续 第 二 个 任务 将 在 
initialDelay+2*period 时 进行 ， 依 此 类 推 。 


e scheduleWithFixedDelay 


o Creates and executes a periodic action that becomes enabled first 
after the given initial delay, and subsequently with the given delay 
between the termination of one execution and the commencement 
of the next. 

o 翻译: 创建 并 执行 一 个 周期 性 任务 。 任 务 开 始 于 初始 延 时 时 
间 ， 后 续 任 务 将 会 按照 给 定 的 延 时 进行 ， 即 上 一 个 任务 的 结束 
时 间 到 下 一 个 任务 的 开始 时 间 的 时 间 差 。 


下 面 的 例子 使 用 scheduleAtFixedRate() 方 法 调度 一 个 任务 。 这 个 任 





务 会 执行 1 秒 钟 时 间 ， 调 度 周期 是 2 秒 。 也 就 是 说 每 2 秒 钟 ， 任 务 就 会 被 
执行 一 次 。 


01 public class ScheduledExecutorServiceDemo { 


02 
03 
04 
05 
06 
07 
08 


public static void main(String[] args) { 
ScheduledExecutorService ses=Executors.newScheduledtThr 
// 如 果 前 面 的 任务 没有 完成 ， 则 调度 也 不 会 启动 
ses.scheduleAtFixedRate(new Runnable() { 
@Override 
public void run() { 


try { 


09 Thread.sleep(1000); 


10 System.out.println(System.currentTimeMilli 
11 } catch (InterruptedException e) { 

12 e.printStackTrace(); 

13 } 

14 } 

15 }, ©, 2, TimeUnit.SECONDS); 

16 } 

ay a 


执行 上 述 代 码 ， 一 种 输出 的 可 能 如 下 : 


1426515345 
1426515347 
1426515349 
1426515351 
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这 里 还 想 说 一 个 有 意思 的 事情 ， 如 有 果 任 务 的 执行 时 间 超 过 调度 时 
间 ， 会 发 生 什 么 情况 呢 ? 比如， 这 里 调度 周期 是 2 秒 ， 如 果 任 务 的 执行 
时 间 是 8 秒 ， 是 不 是 会 出 现 多 个 任务 堆 达 在 一 起 呢 ? 


实际 上 ，ScheduledExecutorService 不 会 让 任务 堆 车 出现。 我 们 将 第 
9 行 的 代码 改 为 : 


Thread.sleep( 8000); 





再 执行 上 述 代 码 ， 你 就 会 发 现任 务 的 执行 周期 不 再 是 2 秒 ， 而 是 变 


成 了 8 秒 。 如 下 所 示 ， 古 一 种 可 能 的 结果 。 


1426516323 
1426516331 
1426516339 
1426516347 
1426516355 





也 就 是 说 ， 周 期 如 果 太 短 ， 那 么 任务 束 会 在 上 一 个 任务 结束 后 ， 广 
即 被 调用 。 可 以 想象 ， 如 果 采 用 scheduleWithFixedDelay()， 并 且 按 照 修 
改 8 秒 ， 调 度 周期 2 秒 计 ， 那 么 任务 的 实际 间隔 将 是 10 秒 ， 大 家 可 以 自行 


尝试 。 








为 外 一 个 值得 注意 的 问题 是 ， 调 度 程序 实际 上 并 不 保证 任务 会 无 限 
期 的 持续 调用 。 如 果 任务 本 喘 抛 出 了 寞 第 ， 那 么 后 续 的 所 有 执行 都 会 被 
中 断 ， 因 此 ， 如 果 你 想 让 你 的 任务 持续 稳定 的 执行 ， 那 么 做 好 有 向 处 理 
就 非常 重要 ， 人 否则 ， 你 很 有 可 能 观察 到 你 的 调度 需 无 疾 而 终 。 


注意 : 如 果 任 务 遇 到 异常 ， 那 么 后 续 的 所 有 子 任务 都 会 停止 调度 ， 
因此 ， 必 须 保证 异常 被 及 时 处 理 ， 为 周期 性 任务 的 稳定 调度 提供 条 
Ie 


3.2.3 UHRA: 核心 线程 池 的 内 部 
实现 


对 于 核心 的 几 个 线程 池 ， 无 论 是 newFixedThreadPool0) 方 法 、 
newSingleThreadExecutor() 还 是 newCachedThreadPool() 方 法 ， 虽 然 看 起 


来 创建 的 线程 有 着 完全 不 同 的 功能 特点 ， 但 其 内 部 实现 均 使 用 了 
ThreadPoolExecutor 实 现 。 下 面 给 出 了 这 三 个 线程 池 的 实现 方式 : 


public static ExecutorService newFixedThreadPool(int nThreads) { 
return new ThreadPoolExecutor(nThreads, nThreads, 
OL, TimeUnit.MILLISECONDS, 


new LinkedBlockingQueue<Runnab. 


public static ExecutorService newSingleThreadExecutor() { 
return new FinalizableDelegatedExecutorService 
(new ThreadPoolExecutor(1, 1, 
OL, TimeUnit.MILLISECONDS, 


new LinkedBlockingQueue<Runnable: 


public static ExecutorService newCachedThreadPool() { 
return new ThreadPoolExecutor(0, Integer .MAX_VALUE, 
60L, TimeUnit.SECONDS, 


new SynchronousQueue<Runnable> 


由 以 上 线程 池 的 实现 代码 可 以 看 到 ， 它 们 都 只 是 
ThreadPoolExecutor 类 的 封装 。 为 何 ThreadPoolExecutor 有 如 此 强大 的 功 
能 呢 ? 来 看 一 下 ThreadPoolExecutor 最 重要 的 构造 孙 数 : 


public ThreadPoolExecutor(int corePoolSize, 


int maximumPoolSize, 


long keepAliveTime, 

TimeUnit unit, 
BlockingQueue<Runnable> workQueue, 
ThreadFactory threadFactory, 


RejectedExecutionHandler handler) 
函数 的 参数 含义 如 下 。 


corePoolSize: 指定 了 线程 池 中 的 线程 数量 。 

e maximumPoolSize: 指定 了 线程 池 中 的 最 大 线程 数量 。 
keepAliveTime: 当 线 程 池 线程 数量 超过 corePoolSize 时 ， 多 余 的 
空闲 线程 的 存活 时 间 。 即 ， 超 过 corePoolSize 的 空闲 线程 ， 在 多 
长 时 间 内 ， 会 被 销毁 。 

e unit: keepAliveTime 的 单位 。 

e workQueue: 任务 队列 ， 被 提交 但 尚未 被 执行 的 任务 。 
threadFactory: 线程 工厂 ， 用 于 创建 线程 ， 一 般 用 默认 的 即 可 。 
handler: 拒绝 策略 。 当 任务 太 多 来 不 及 处 理 ， 如 何 拒绝 任务 。 





以 上 参数 中 ， 大 部 分 都 很 简单 ， 只 有 workQueue 和 handler 需 要 进行 
详细 说 明 。 

参数 workQueue 指 被 提交 但 未 执行 的 任务 队列 ， 它 是 一 个 
BlockingQueue 接 口 的 对 象 ， 仅 用 于 存放 Runnable 对 象 。 根 据 队 列 功能 分 


类 ， 在 ThreadPoolExecutor 的 构造 函数 中 可 使 用 以 下 几 种 
BlockingQueue. 


。 直接 提交 的 队列 : 该 功能 由 SynchronousQueue 对 象 提供 。 


SynchronousQueue 是 一 个 特殊 的 BlockingQueue。 


SynchronousQueue 没 有 容量 ， 每 一 个 插入 操作 都 要 等 待 一 个 相应 
的 删除 操作 ， 反 之 ， 每 一 个 删除 操作 都 要 等 待 对 应 的 插入 操作 。 
如 果 使 用 SynchronousQueue， 提 交 的 任务 不 会 被 真实 的 保存 ， 而 
总 是 将 新 任务 提交 给 线程 执行 ， 如 果 没 有 空间 的 进程 ， 则 尝试 创 
建新 的 进程 ， 如 果 进 程 数 量 已 经 达到 最 大 值 ， 则 执行 拒绝 策略 。 
因此 ， 使 用 SynchronousQueue 队 列 ， 通 常 要 设置 很 大 的 
maximumPoolSize 值 ， 人 否则 很 容易 执行 拒绝 策略 。 

有 界 的 任务 队列 : 有 界 的 任务 队列 可 以 使 用 ArrayBlockingQueue 
实现 。ArrayBlockingQueue 的 构造 函数 必须 带 一 个 容量 参数 ， 表 
示 该 队列 的 最 大 容量 ， 如 下 上 所 示 。 











public ArrayBlockingQueue(int capacity) 


当 使 用 有 界 的 任务 队列 时 ， 知 有 新 的 任务 需要 执行 ， 如 果 线 程 
池 的 实际 线程 数 小 于 corePoolSize， 则 会 优先 创建 新 的 线程 ， 若 
大 于 corePoolSize， 则 会 将 新 任务 加 入 等 竺 队列 。 知 等 竺 队列 已 
满 ， 无 法 加 入 ， 则 在 总 线程 数 不 大 于 maximumPoolSize 的 前 提 

下 ， 创 建新 的 进程 执行 任务 。 奉 大 于 maximumPoolSize， 则 执行 
拒绝 策略 。 可 见 ， 有 界 队列 仪 当 在 任务 队列 装 满 时 ， 才 可 能 将 
线程 数 提升 到 corePoolSize 以 上 上， 换言之， 除非 系统 非常 繁忙 ， 

侍 则 确保 核心 线程 数 维持 在 在 corePoolSize。 


。 无 界 的 任务 队列 : 无 界 任 务 队 列 可 以 通过 LinkedBlockingQueue 类 
实现 。 与 有 界 队 列 相 比 ， 除 非 系统 资源 耗 尽 ， 人 否则 无 界 的 任务 队 
列 不 存在 任务 入 队 失 败 的 情况 。 当 有 新 的 任务 到 来 ， 系 统 的 线程 
数 小 于 corePoolSize 时 ， 线 程 池 会 生成 新 的 线程 执行 任务 ， 但 当 
系统 的 线程 数 达 到 corePoolSize 后 ， 就 不 会 继续 增加 。 知 后 续 仍 
有 新 的 任务 加 入 ， 而 又 没有 空闲 的 线程 资源 ， 则 任务 直接 进入 队 





列 等 待 。 奋 任务 创建 和 处 理 的 速度 差异 很 大 ， 无 界 队 列 会 保持 快 
速 增长 ， 直 到 耗 尽 系统 内 存 。 

优先 任务 队列 : 优先 任务 队列 是 融 有 执行 优先 级 的 队列 。 它 通过 
PriorityBlockingQueue 实 现 ， 可 以 控制 任务 的 执行 先后 顺序 。 它 
是 一 个 特殊 的 无 界 队 列 。 无 论 是 有 界 队列 ArrayBlockingQueue， 
还 是 未 指定 大 小 的 无 界 队列 LinkedBlockingQueue 都 是 按照 先进 先 
出 算法 处 理 任 务 的 。 而 PriorityBlockingQueue 则 可 以 根据 任务 自 
号 的 优先 级 顺序 先后 执行 ， 在 确保 系统 性 能 的 同时 ， 也 能 有 很 好 
的 质量 保证 《总 是 确保 高 优先 级 的 任务 先 执行 ) 。 


回顾 newFixedThreadPool(0 方 法 的 实现 。 它 返回 了 一 个 corePoolSize 
和 maximumPoolSize 大 小 一 样 的 ， 并 且 使 用 了 LinkedBlockingQueue 任 务 
队列 的 线程 池 。 因 为 对 于 固定 大 小 的 线程 池 而 言 ， 不 存在 线程 数量 的 动 
态 变 化 ， 因 此 corePoolSize 和 maximumPoolSize 可 以 相等 。 同 时 ， 它 使 用 
无 界 队 列 存放 无 法 立即 执行 的 任务 ， 当 任务 提交 非常 频繁 的 时 候 ， 该 队 
列 可 能 迅速 膀 胀 ， 从 而 耗 套 系统 资源 。 


newSingleThreadExecutorO 返 回 的 单线 程 线 程 池 ， 是 
newFixedThreadPool0 方 法 的 一 种 退化 ， 只 是 简单 的 将 线程 池 线 程 数量 
设置 为 1。 


newCachedThreadPool0 方 法 返回 corePoolSize 为 0， 
maximumPoolSize 无 穷 大 的 线程 池 ， 这 意味 着 在 没有 任务 时 ， 该 线程 池 
内 无 线程 ， 而 当 任 务 被 提交 时 ， 该 线程 池 会 使 用 空闲 的 线程 执行 任务 ， 
各 无 空 采 线程 ， 则 将 任务 加 入 SynchronousQueue 队 列 ， 而 
SynchronousQueue 队 列 是 一 种 直接 提交 的 队列 ， 它 总 会 迫使 线程 池 增 加 
新 的 线程 执行 任务 。 当 任务 执行 完毕 后 ， 由 于 corePoolSize 为 0， 因 此 至 
朵 线程 又 会 在 指定 时 间 内 〈60 秒 ) 被 回收 。 











对 于 newCachedThreadPool0， 如 果 同 时 有 大 量 任务 被 提交 ， 而 任务 的 执 
行 又 不 那么 快 时 ， 那 么 系统 便 会 开局 等 量 的 线程 处 理 ， 这 样 做 法 可 能 会 
很 快 耗 尽 系统 的 资源 。 


JER: 使 用 自 定 义 线 程 池 时 ， 要 根据 应 用 的 具体 情况 ， 选 择 合适 的 
并 发 队列 作为 任务 的 缓冲 。 当 线程 资源 紧张 时 ， 不同 的 并 发 队列 对 
系统 行为 和 性 能 的 影响 均 不 同 。 


这 里 给 出 ThreadPoolExecutor 线 程 池 的 核心 调度 代码 ， 这 上 段 代 码 也 
充分 体现 了 上 述 线程 池 的 工作 逻辑 : 


01 public void execute(Runnable command) { 


02 if (command == null) 

03 throw new NullPointerException()j; 

04 int c = ctl.get(); 

05 if (workerCountOf(c) < corePoolSize) { 

06 if (addWorker(command, true) ) 

07 return; 

08 c = ctl.get(); 

09 } 

10 if (isRunning(c) && workQueue.offer(command)) { 
11 int recheck = ctl.get(); 

12 if (! isRunning(recheck) && remove(command ) ) 
13 reject(command); 

14 else if (workerCountOf(recheck) == 0) 

15 addworker(null, false); 

16 } 


17 else if (!addWorker(command, false)) 


18 reject(command) ; 


‘ge 


代码 第 5 行 的 workerCountOfO 函 数 取 得 了 当前 线程 池 的 线程 总 数 。 
当 线 程 总 数 小 于 corePoolSize 核 心 线程 数 时 ， 会 将 任务 通过 addWorker0) 
方法 直接 调度 执行 。 否 则 ， 则 在 第 10 行 代码 处 CworkQueue.offer()) it 
入 等 竺 队列。 如 果 进 入 等 竺 队列 失败 《比如 有 界 队 列 到 达 了 上 限 ， 或 者 
使 用 了 SynchronousQueue) ， 则 会 执行 第 17 行 ， 将 任务 直接 提交 给 线程 
池 。 如 果 当 前 线程 数 已 经 达到 maximumPoolSize， 则 提交 失败 ， 就 执行 
第 18 行 的 拒绝 策略 。 





调度 逻辑 可 以 总 结 为 如 图 3.6 所 示 。 
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3.2.4 超 负 载 了 怎么 办 : 拒绝 策略 


ThreadPoolExecutor 的 最 后 一 个 参数 搬 定 了 拒绝 策略 。 也 就 是 当 任 
务 数量 超过 系统 实际 承载 能 力 时 ， 该 如 何 处 理 呢 ? 这 时 就 要 用 到 拒绝 策 
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服务 ， 同 时 ， 等 待 队列 中 也 己 经 排 满 了 ， 再 也 蹇 不 下 新 任务 了 。 这 时 ， 
我 们 就 需要 有 一 套 机 制 ， 合 理 地 处 理 这 个 问题 。 


JDK 内 置 提 供 了 四 种 拒绝 策略 ， 如 图 3.7 所 示 。 


日 9 RejectedExecutionHandler - java.util. concurrent 


(CH AbortPolicy - java. util. concurrent. ThreadPoolE: 
(CH CallerRunsPolicy - java. util. concurrent. Thread 
(CH Discard0ldestPolicy - java. util. concurrent. Thr 


(CH DiscardPolicy - java. util. concurrent. ThreadPoo: 


图 3.7 JDK 内 置 的 拒绝 策略 
JDK 内 置 的 拒绝 策略 如 下 。 


e AbortPolicy 策 略 : 该 策略 会 直接 抛 出 异常 ， 阻 止 系统 正常 工作 。 
e CallerRunsPolicy 策 略 : 只 要 线程 池 未 关闭 ， 该 策略 直接 在 调用 者 
线程 中 ， 运 行当 前 被 丢弃 的 任务 。 显 然 这 样 做 不 会 真 的 丢弃 任 

务 ， 但 是 ， 任 务 提 交 线 程 的 性 能 极 有 可 能 会 急剧 下 降 。 

e DiscardOledestPolicy 策 略 : 该 策略 将 丢弃 最 老 的 一 个 请 求 ， 也 就 
是 即将 被 执行 的 一 个 任务 ， 并 尝试 再 次 提交 当前 任务 。 

。 DiscardPolicy 策 略 : 该 策略 默默 地 丢弃 无 法 处 理 的 任务 ， 不 予 任 
何 处 理 。 如 果 人 允许 任务 丢失 ， 我 觉得 这 可 能 是 最 好 的 一 种 方案 了 
Ne! 

















以 上 内 置 的 策略 均 实 现 了 RejectedExecutionHandler 接 口 ， 若 以 上 策 
略 仍 无 法 满足 实际 应 用 需要 ， 完 全 可 以 自己 扩展 
RejectedExecutionHandler 接 口 。RejectedExecutionHandler 的 定义 如 下 : 


public interface RejectedExecutionHandler { 


void rejectedExecution(Runnable r, ThreadPoolExecutor executo 


其 中 z 为 请 求 执 行 的 任务 ，executor 为 当前 的 线程 池 。 
下 面 的 代码 简单 地 演示 了 目 定 义 线程 池 和 拒绝 策略 的 使 用 : 


01 public class RejectThreadPoolDemo { 


02 
03 
04 
05 
06 
07 
08 
09 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 


public static class MyTask implements Runnable { 
@Override 
public void run() { 
System.out.printin(System.currentTimeMillis() + ": 
+ Thread.currentThread().getId()); 
try { 
Thread.sleep(100); 
} catch (InterruptedException e) { 


e.printStackTrace(); 


public static void main(String[] args) throws InterruptedE 
MyTask task = new MyTask(); 
ExecutorService es = new ThreadPoolExecutor(5, 5, 
OL, TimeUnit.MILLISECONDS, 
new LinkedBlockingQueue<Runnable> (10), 
Executors.defaultThreadFactory(), 
new RejectedExecutionHandler ( ) { 
@Override 


public void rejectedExecution(Runnable r, 


24 ThreadPoolExecutor executor) { 


25 System.out.printin(r.toString()+" is d 


27 }); 
28 for (int i = 0; i < Integer.MAX_VALUE; i++) { 
29 es.submit(task); 


30 Thread.sleep(10); 


上 述 代码 的 第 17 一 27 行 自 定 义 了 一 个 线程 池 。 该 线程 池 有 5 个 常 驻 
线程 ， 并 且 最 大 线程 数量 也 是 5 个 。 这 和 固定 大 小 的 线程 池 是 一 样 的 。 
但 是 它 却 拥有 一 个 只 有 10 个 容量 的 等 竺 队列 。 因 为 使 用 无 界 队列 很 可 能 
并 不 是 最 佳 解决 方案 ， 如 果 任 务 量 极 大 ， 很 有 可 能 会 把 内 存 撑 爆 。 给 出 
一 个 合理 的 队列 大 小 ， 也 是 合乎 第 理 的 选择 。 同 时 ， 这 里 自 定 义 了 拒绝 
策略 ， 我 们 不 抛 出 异常 ， 因 为 万 一 在 任务 提交 站 没有 进行 异常 处 理 ， 则 
有 可 能 使 得 整个 系统 都 骨 演 ， 这 极 有 可 能 不 是 我 们 希望 过 到 的 。 但 作为 
必要 的 信息 记录 ， 我 们 将 任务 丢弃 的 信息 进行 打印 ， 当 然 ， 这 只 比 内 置 
的 DiscardPolicy 策 略 高 级 那么 一 点 点 。 














由 于 在 这 个 案例 中 ，MyTask 执 行 需要 人 花费 100 坚 秒 ， 因 此 ， 必 然 会 
导致 大 量 的 任务 被 直接 丢弃 。 执 行 上 述 代 码 ， 可 能 的 部 分 输出 如 下 : 


1426597264669:Thread ID:11 
1426597264679:Thread ID:12 
java.util.concurrent.FutureTask@a57993 is discard 


java.util.concurrent.FutureTask@1b84c92 is discard 


可 以 看 到 ， 在 执行 几 个 任务 后 ， 拒 绝 策略 就 开始 生效 了 。 在 实际 应 
用 中 ， 我 们 可 以 将 更 详细 的 信息 记录 到 日 志 中 ， 来 分 析 系 统 的 负载 和 任 
BERN AU 


3.2.5” 目 定义 线程 创建 : 
ThreadFactory 





看 了 那么 多 有 关 线 程 池 的 介绍 ， 不 知道 大 家 有 没有 思考 过 一 个 基本 
的 问题 : 那 就 是 线程 池 中 的 线程 是 从 哪里 来 的 呢 ? 





之 前 我 们 介绍 过 ， 线 程 池 的 主要 作用 是 为 了 线程 复 用 ， 也 就 是 避免 
了 线程 的 频 楷 创建 。 但 是 ， 最 开始 的 那些 线程 从 何 而 来 呢 ? AR he 
ThreadFactory。 








ThreadFactory 是 一 个 接口 ， 它 只 有 一 个 方法 ， 用 来 创建 线程 : 
Thread newThread(Runnable r); 
当 线 程 池 需 要 新 建 线程 时 ， 就 会 调用 这 个 方法 。 


自 定 义 线 程 池 可 以 帮助 我 们 做 不 少 事 。 比 如 ， 我 们 可 以 跟 踩 线程 池 
究竟 在 何 时 创建 了 多 少 线程 ， 也 可 以 自 定 义 线程 的 名 称 、 组 以 及 优先 级 
等 信息 ， 甚 至 可 以 任性 地 将 所 有 的 线程 设置 为 守护 线程 。 总 之 ， 使 用 自 
定义 线程 池 可 以 让 我 们 更 加 自由 地 设置 池子 中 所 有 线程 的 状态 。 下 面 的 
案例 使 用 目 定 义 的 ThreadFactory， 一 方面 记录 了 线程 的 创建 ， 另 一 方面 
将 所 有 的 线程 都 设置 为 守护 线程 ， 这 样 ， 当 主线 程 退 出 后 ， 将 会 强制 销 
BZ Feith o 





01 public static void main(String[] args) throws InterruptedExcep 


02 MyTask task = new MyTask(); 

03 ExecutorService es = new ThreadPoolExecutor(5, 5, 
04 OL, TimeUnit.MILLISECONDS, 

05 new SynchronousQueue<Runnable>(), 

06 new ThreadFactory(){ 

07 @Override 

08 public Thread newThread(Runnable r) { 
09 Thread t= new Thread(r); 

10 t.setDaemon(true); 

ed System.out.printin("create "+t); 
12 return t; 

13 } 

14 } 

15 ); 

16 ror (une 1 = ©; 1 < 57 mi) 4 

17 es.submit(task); 

18 } 

19 Thread.sleep(2000); 

20 } 


3.2.6 ”我 的 应 用 我 做主 : 扩展 线程 池 


虽然 JDK 己 经 帮 我 们 实现 了 这 个 稳定 的 高 性 能 线程 池 。 但 如 果 我 们 
需要 对 这 个 线程 池 做 一 些 扩展 ， 比 如 ， 我 们 想 监 控 每 个 任务 执行 的 开始 
和 结束 时 间 ， 或 者 其 他 一 些 目 定 义 的 增强 功能 ， 这 时 候 应 该 怎么 办 呢 ? 


一 个 好 消息 是 : ThreadPoolExecutor 也 是 一 个 可 以 扩展 的 线程 池 。 
它 提供 了 beforeExecute()、afterExecute() 和 terminated() 三 个 接口 对 线程 池 
进行 控制 。 


以 beforeExecute()、afterExecute() 为 例 ， 在 
ThreadPoolExecutor.Worker. runTask() 方 法 内 部 提供 了 这 样 的 实现 : 


boolean ran = false; 


beforeExecute(thread, task); // 运 行 前 
try { 
task.run(); // 运 行 任务 


ran = true; 
afterExecute(task, null); // 运 行 结束 ) 
++completedTasks; 
} catch (RuntimeException ex) { 
if (!ran) 
afterExecute(task, ex); // 运 行 结束 


throw ex; 


ThreadPoolExecutor.Worker 是 ThreadPoolExecutor 的 内 部 类 ， 它 是 一 
个 实现 了 Runnable 接 口 的 类 。ThreadPoolExecutor 线 程 池 中 的 工作 线程 也 
正 是 worker 实 例 。Worker.runTask() 方 法 会 被 线程 池 以 多 线程 模式 异步 
调用 ， 即 Worker.runTask0 会 同时 被 多 个 线程 访问 。 因 此 其 
beforeExecute()、afterExecute() 接 口 也 将 同时 多 线程 访问 。 


在 默认 的 ThreadPoolExecutor 实 现 中 ， 提 供 了 空 的 beforeExecute() 和 
afterExecute() 实 现 。 在 实际 应 用 中 ， 可 以 对 其 进行 扩展 来 实现 对 线程 池 








运行 状态 的 跟踪 ， 输 出 一 些 有 用 的 调试 信息 ， 以 帮助 系统 故障 诊断 ， 这 
对 于 多 线程 程序 错误 排查 是 很 有 帮助 的 。 下 面 演示 了 对 线程 池 的 扩展 ， 





在 这 个 扩展 中 ， 我 们 将 记录 每 一 个 任务 的 执行 日 志 。 


01 public class ExtThreadPool { 


02 
03 
04 
05 
06 
07 
08 
09 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 


public static class MyTask implements Runnable { 


public String name; 


public MyTask(String name) { 


this.name = name; 


@Override 
public void run() { 
System.out.println(" 正 在 执行 " + ":Thread ID:" + Thre 
+ ", Task Name=" + name); 
try { 
Thread.sleep(100) ; 
} catch (InterruptedException e) { 


e.printStackTrace(); 


public static void main(String[] args) throws InterruptedE 


ExecutorService es = new ThreadPoolExecutor(5, 5, OL, Ti 


new LinkedBlockingQueue<Runnable>()) { 
@Override 
protected void beforeExecute(Thread t, Runnable r) 


System.out.printlLn(" 准 备 执行 : " + ((MyTask) r).n 


@Override 
protected void afterExecute(Runnable r, Throwable 


System,out.printlLn(" 执 行 完 成 : " + ((MyTask) r).n 


@Override 
protected void terminated() { 


System,out,.println(" 线 程 池 退出 ") ， 


OIL 三 
MyTask task = new MyTask("TASK-GEYM-" + i); 
es.execute(task); 
Thread.sleep(10); 

} 


es.shutdown(); 


上 述 代 码 在 第 23 一 40 行 ， 扩 展 了 原 有 的 线程 池 ， 实 现 了 


beforeExecute()、afterExecute() 和 terminiated() 三 个 方法 。 这 三 个 方法 分 
列 用 于 记录 一 个 任务 的 开始 、 结 束 和 整个 线程 池 的 退出 。 在 第 42 一 43 
行 ， 回 线程 池 提交 5 个 任务 ， 为 了 有 更 清晰 的 日 志 ， 我 们 为 每 个 任务 都 
取 了 一 个 不 同 的 名 字 。 第 43 行 使 用 execute(0) 方 法 提交 任务 ， 细 心 的 读者 
一 定 发 现 ， 在 之 前 代码 中 ， 我 们 都 使 用 了 submit() 方 法 提交 ， 有 关 两 者 
的 区 别 ， 我 们 将 在 “5.5 节 Future 模 式 ” 中 详细 介绍 。 





在 提交 完成 后 ， 调 用 shutdown() 方 法 关闭 线程 池 。 这 是 一 个 比较 安 
全 的 方法 ， 如 果 当 前 正 有 线程 在 执行 ，shutdown() 方 法 并 不 会 立即 暴力 
地 终止 所 有 任务 ， 它 会 等 待 所 有 任务 执行 完成 后 ， 再 关闭 线程 池 ， 但 它 
并 不 会 等 待 所 有 线程 执行 完成 后 再 返回 ， 因 此 ， 可 以 简单 地 理解 成 
shutdownO 只 是 发 送 了 一 个 关闭 信号 而 已 。 但 在 shutdown() 方 法 执行 后 ， 
这 个 线程 池 就 不 能 再 接受 其 他 新 的 任务 了 。 











执行 上 述 代码 ， 可 以 得 到 类 似 以 下 的 输出 : 


准备 执行 : TASK-GEYM-0 
正在 执行 :Thread ID:8, Task Name=TASK-GEYM-0 
准备 执行 : TASK-GEYM-1 
正在 执行 :Thread ID:9,Task Name=TASK-GEYM-1 
准备 执行 : TASK-GEYM-2 
正在 执行 :Thread ID:10,Task Name=TASK-GEYM-2 
准备 执行 : TASK-GEYM-3 
正在 执行 :Thread ID:11, Task Name=TASK-GEYM-3 
准备 执行 : TASK-GEYM-4 
正在 执行 :Thread ID:12,Task Name=TASK-GEYM-4 
执行 完成 : TASK-GEYM-0 
执行 完成 : TASK-GEYM-1 


执行 完成 : TASK-GEYM-2 
执行 完成 : TASK-GEYM-3 
执行 完成 : TASK-GEYM-4 
线程 池 退 出 


可 以 看 到 ， 所 有 任务 的 执行 前 、 执 行 后 的 时 间 点 以 及 任务 的 名 字 都 
己 经 可 以 捕获 了 。 这 对 于 应 用 程序 的 调试 和 诊断 是 非常 有 帮助 的 。 


3.2.7 合理 的 选择 : 优化 线程 池 线 程 
数量 


线程 池 的 大 小 对 系统 的 性 能 有 一 定 的 影响 。 过 大 或 者 过 小 的 线程 数 
量 都 无 法 发 挥 最 优 的 系统 性 能 ， 但 是 线程 池 大 小 的 确定 也 不 需要 做 得 非 
第 精确 ， 因 为 只 要 避免 极 大 和 极 小 两 种 情况 ， 线 程 池 的 大 小 对 系统 的 性 
能 并 不 会 影响 大大。 一般 来 次， 确定 线程 池 的 大 小 需要 考虑 CPU 数量 、 
内 存 大 小 等 因素 。 在 《Java Concurrency in Practice》 一 书 中 给 出 了 一 个 
估算 线程 池 大 小 的 经 验 公式 : 




















Ncpu = CPU 的 数量 
Ucpu = 目标 CPU 的 使 用 率 ，0<Ucpus 1 
W/C = 等 竺 时 间 与 计算 时 间 的 比率 





为 保持 处 理 吉 达到 期 望 的 使 用 率 ， 最 优 的 池 的 大 小 等 于 : 
Nthreads = Ncpu * Ucpu * (1+ W/C ) 


在 Java 中 ， 可 以 通过 : 


Runtime.getRuntime().availableProcessors() 


取得 可 用 的 CPU 数量 。 


3.2.8 ”堆栈 去 哪里 了 : 在 线程 池 中 寻 
FR HERK 
大 家 一 定 还 记得 在 上 一 章 中 ， 我 们 详解 介绍 了 一 些 幽 灵 般 的 错误 。 


我 想 ， 码 农 的 痛 苗 也 英 过 于 此 了。 多 线程 本 映 就 是 非常 容易 引起 这 类 错 
误 的 。 如 末 你 使 用 了 线程 池 ， 那 么 这 种 幽灵 错误 可 能 会 变 得 更 加 常见 。 

















下 面 来 看 一 个 简单 的 和 案例， 首先 ， 我 们 有 一 个 Runnable 接 口 ， 它 用 
来 计算 两 个 数 的 商 : 
public class DivTask implements Runnable { 


int a,b; 


public DivTask(int a,int b){ 


this.a=a; 
this.b=b; 
} 
@Override 


public void run() { 
double re=a/b; 


System.out.println(re); 


如 果 程 序 运 行 了 这 个 任务 ， 那 么 我 们 期 望 它 可 以 打印 出 给 定 两 个 数 
的 丙 。 现 在 我 们 构造 几 个 这 样 的 任务 ， 和 希望 程序 可 以 为 我 们 计算 一 组 给 
定数 组 的 商 : 


public static void main(String[] args) throws InterruptedExceptio 
ThreadPoolExecutor pools=new ThreadPoolExecutor(0, Integer.MA 
OL, TimeUnit.SECONDS, 


new SynchronousQueue<Runnable>()); 


for(int 1=0;1<5;1i++){ 


pools.submit(new DivTask(100,1)); 


上 述 代码 将 DivTask 提 交 到 线程 池 ， 从 这 个 for 循 环 来 看 ， 我 们 应 该 
会 得 到 5 个 结果 ， 分 别 是 100 除 以 给 定 的 i 后 的 商 。 但 如 果 你 真 的 运行 程 
序 ， 你 得 到 的 全 部 结果 是 : 


33.0 
50.0 
100.0 
25.0 











你 没有 看 错 ! KANA. Hattie cers S RE 但 更 
不 注 的 是 ， 程 序 没有 任何 日 志 ， 没 有 任何 错误 提示 ， 束 好 像 一 切 都 正常 
一 样 。 在 这 个 简单 的 案例 中 ， 只 要 你 稍 有 经 验 ， 你 就 能 发 现 ， 作 为 除数 
的 取 到 了 0， 这 个 缺失 的 值 很 可 能 是 由 于 除 以 0 导致 的 。 但 在 稍 复杂 的 
业务 场景 中 ， 这 种 错误 足 可 以 让 你 几 天 萎靡 不 振 。 














因此 ， 使 用 线程 池 虽 然 是 件 好 事 ， 但 是 还 是 得 处 处 留意 这 些 “ 抗 ”。 
线程 池 很 有 可 能 会 “ 吃 ” 掉 程序 抛 出 的 异常 ， 导 致 我 们 对 程序 的 错误 一 无 
所 知 。 








异常 堆栈 对 于 程序 员 的 重要 性 就 好 像 指 南 针对 于 范 范 大 海上 的 舱 
只 。 没 有 指南 针 ， 船 只 只 能 更 艰难 地 寻找 方向 ， 没 有 异 第 堆栈 ， 排 查 问 
题 时 ， 也 只 能 像 大 海 捞 针 那样 ， 慢 慢 琢 磨 了 。 我 的 一 个 领导 曾经 说 过 : 
最 于 视 那 些 出 错 不 打印 异常 堆栈 的 行为 ! 我 相信 ， 任 何 一 个 得 荔 于 异常 
堆栈 而 快速 定位 问题 的 程序 员 来 说 ， 一 定 对 这 人 句 话 深 有 体会 。 所 以 ， 这 
里 我 们 将 和 大 家 讨论 向 线程 池 讨 回 寞 常 堆栈 的 方法 。 

















一 种 最 简单 的 方法 ， 就 是 放弃 submit()， 改 用 execute()。 将 上 述 的 任 
务 提 交代 人 码 改 成 : 


pools.execute(new DivTask(100,i)); 


或 者 你 使 用 下 面 的 方法 改造 你 的 submitO: 


Future re=pools.submit(new DivTask(100,1)); 


re.get(); 


上 面 两 种 方法 都 可 以 得 到 部 分 堆栈 信息 ， 如 下 所 示 : 


Exception in thread "pool-1-thread-1" java.lang.ArithmeticExcepti 
at geym.conc.ch3.trace.DivTask.run(DivTask.java:11) 
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoo 
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPo 
at java.lang.Thread.run(Thread. java: 745) 

33.0 


100.0 
50.0 
25M0 


注意 了 ， 我 这 里 说 的 是 部 分 。 这 是 因为 从 这 两 个 异常 堆栈 中 我 们 只 
能 知道 异常 是 在 哪里 抛 出 的 〈 这 里 是 DivTask 的 第 11 行 ) 。 但 是 我 们 还 
希望 得 到 另外 一 个 更 重要 的 信息 ， 那 就 是 这 个 任务 到 底 是 在 哪里 提交 
的 ? 而 任务 的 具体 提交 位 置 已 经 被 线程 池 完 全 淹没 了 。 顺 着 堆栈 ， 我 们 
最 多 只 能 找到 线程 池 中 的 调度 流程 ， 而 这 对 于 我 们 几乎 是 没有 价值 的 。 








既然 这 样 ， 我 们 只 能 自己 动手 ， 丰 衣 足 食 啦 ! 为 了 今后 少 加 几 天 
班 ， 我 们 还 是 非常 有 必要 将 堆栈 的 信息 彻底 挖 出 来 ! 扩展 我 们 的 
ThreadPoolExecutor 线 程 池 ， 让 它 在 调度 任务 之 前 ， 先 保存 一 下 提交 任 
务 线程 的 堆栈 信息 。 如 下 所 示 : 








01 public class TraceThreadPoolExecutor extends ThreadPoolExecuto 


02 public TraceThreadPoolExecutor(int corePoolSize, int maxim 
03 long keepAliveTime, TimeUnit unit, BlockingQueue<t 
04 super(corePoolSize, maximumPoolSize, keepAliveTime, un 
05 } 

06 

07 @Override 

08 public void execute(Runnable task) { 

09 super .execute(wrap(task, clientTrace(), Thread.current 
10 .getName())); 

11 } 

12 


13 @Override 


14 public Future<?> submit(Runnable task) { 


15 return Super.submit(wrap(task, clientTrace(), Thread.c 
16 .getName())); 

17 } 

18 

19 private Exception clientTrace() { 

20 return new Exception("Client stack trace"); 
21 } 

22 

23 private Runnable wrap(final Runnable task, final Exception 
24 String clientThreadName) { 

25 return new Runnable() { 

26 @Override 

27 public void run() { 

28 try { 

29 task.run(); 

30 } catch (Exception e) { 

31 clientStack.printStackTrace(); 
32 throw e; 

33 J 

34 } 

35 }; 

36 } 

37 } 





在 第 23 行 代码 中 ，wrap() 方 法 的 第 2 个 参数 为 一 个 异常 ， 里 面 保存 着 
提交 任务 的 线程 的 堆栈 信息 。 该 方法 将 我 们 传 入 的 Runnable 任 务 进行 一 





层 包 装 ， 使 之 能 处 理 噶 向 信 息 。 当 任务 发 生 异 常 时 ， 这 个 异 第 会 被 打 
印 。 





好 了 ， 现 在 可 以 使 用 我 们 的 新 成 员 〈TraceThreadPoolExecutor) 来 
MT XB: 


14 public static void main(String[] args) { 


15 ThreadPoolExecutor pools=new TraceThreadPoolExecutor(0, In 
16 OL, TimeUnit.SECONDS, 

17 new SynchronousQueue<Runnable>()); 
18 

19 ee 

20 音 误 堆 栈 中 可 以 看 到 是 在 哪里 提交 的 任务 

21 ars 

22 for(int 1=0;1<5;1i++){ 

23 pools.execute(new DivTask(100,1)); 
24 } 

25 } 


执行 上 述 代 码 ， 就 可 以 得 到 以 下 信息 : 


java.lang.Exception: Client stack trace 
at geym.conc.ch3.trace.TraceThreadPoolExecutor.clientTrace(Tra 
at geym.conc.ch3.trace.TraceThreadPoolExecutor.execute(TracetTh 
at geym.conc.ch3.trace.TraceMain.main(TraceMain. java: 23) 
Exception in thread "pool-1-thread-1" java.lang.ArithmeticExcepti 
at geym.conc.ch3.trace.DivTask.run(DivTask. java:11) 


at geym.conc.ch3.trace.TraceThreadPoolExecutor$1.run(TraceThre 


at java.util.concurrent.ThreadPoolExecutor.runworker(ThreadPoo 
at java.util.concurrent.ThreadPoolExecutor$Wworker.run(ThreadPo 
at java.lang.Thread.run(Thread. java: 745) 
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熟悉 的 异常 又 回来 了 ! 现在 ， 我 们 不 仅 可 以 得 到 异常 发 生 的 
Runnable 实 现 内 的 信息 ， 我 们 也 知道 了 这 个 任务 是 在 哪里 提交 的 。 如 此 
丰富 的 信息 ， 我 相信 可 以 帮助 我 们 瞬间 定位 问题 ! 


3.2.9 分 而 治之 : Fork/Join 框 架 





“分 而 治之 ”一 直 是 一 个 非常 有 效 地 处 理 大 量 数据 的 方法 。 著 名 的 
MapReduce 也 是 采取 了 分 而 治之 的 思想 。 简 单 来 说 ， 就 是 如 果 你 要 处 理 
1000 个 数据 ， 但 是 你 并 不 具备 处 理 1000 个 数据 的 能 力 ， 那 么 你 可 以 只 处 
理 其 中 的 10 个 ， 然 后 ， 分 阶段 处 理 100 次 ， 将 100 次 的 结果 进行 合成 ， 那 
就 是 最 终 想 要 的 对 原始 1000 个 数据 的 处 理 结果 。 








Fork 一 词 的 原始 含义 是 吃饭 用 的 叉子 ， 也 有 分 叉 的 意思 。 在 Linux 
平台 中 ， 函 数 fork0O 用 来 创建 子 进程 ， 使 得 系统 进程 可 以 多 一 个 执行 分 
文 。 在 Java 中 也 沿用 了 类 似 的 命名 方式 。 











而 join() 的 含义 在 之 前 的 章节 中 己 经 解释 过 ， 这 里 也 是 相同 的 意 
思 ， 表 示 等 待 。 也 就 是 使 用 forkO 后 系统 多 了 一 个 执行 分 文 〈 线 程 ) ， 
所 以 需要 等 待 这 个 执行 分 支 执行 完毕 ， 才 有 可 能 得 到 最 终 的 结果 ， 因 此 





join AA BFF 


在 实际 使 用 中 ， 如 果 训 无 顾忌 地 使 用 forkO 开 局 线程 进行 处 理 ， 那 
么 很 有 可 能 导致 系统 开局 过 多 的 线程 而 严重 影响 性 能 。 所 以 ， 在 JDK 
中 ， 给 出 了 一 个 ForkJoinPool 线 程 池 ， 对 于 fork() 方 法 并 不 急 着 开启 线 
程 ， 而 是 提交 给 ForkJoinPool 线 程 池 进 行 处 理 ， 以 节省 系统 资源 。 使 用 
Fork/Join 进 行 数据 处 理 时 的 总 体 结 构 如 图 3.8 所 示 。 





图 3.8 Fork/Join 执 行 逻 辑 





由 于 线程 池 的 优化 ， 提 交 的 任务 和 线程 数量 并 不 是 一 对 一 的 关系 。 
在 绝 大 多 数 情 况 下 ， 一 个 物理 线程 实际 上 是 需要 处 理 多 个 逻辑 任务 的 。 
因此 ， 每 个 线程 必然 需要 拥有 一 个 任务 队列 。 因 此 ， 在 实际 执行 过 程 
中 ， 可 能 遇 到 这 么 一 种 情况 : 线程 A 已 经 把 自己 的 任务 都 执行 完成 了 ， 





而 线程 B 还 有 一 堆 任务 等 着 处 理 ， 此 时 ， 线 程 A 就 会 “帮助 ”线程 B， 从 线 
程 B 的 任务 队列 中 拿 一 个 任务 过 来 处 理 ， 尽 可 能 地 达到 平衡 。 如 图 3.9 所 
示 ， 显 示 了 这 种 互相 帮助 的 精神 。 一 个 值得 注意 的 地 方 是 ， 当 线程 试图 
帮助 别人 时 ， 总 是 从 任务 队列 的 底部 开始 拿 数据 ， 而 线程 试图 执行 自己 
的 任务 时 ， 则 是 从 相反 的 顶部 开始 拿 。 因 此 这 种 行为 也 十 分 有 利于 避免 
数据 苋 搜 。 














图 3.9 互相 帮助 的 线程 


下 面 我 们 来 看 一 下 ForkJoinPool 的 一 个 重要 的 接口 : 


public <T> ForkJoinTask<T> submit(ForkJoinTask<T> task) 


你 可 以 同 ForkJoinPool 线 程 池 提交 一 个 ForkJoinTask 任 务 。 所 请 
ForkJoinTask 任 务 就 是 支持 fork() 分 解 以 及 join0 等 待 的 任务 。 
ForkJoinTask 有 两 个 重要 的 子 类 ，RecursiveAction 和 RecursiveTask。 它 们 
分 别 表示 没有 返回 值 的 任务 和 可 以 携带 返回 值 的 任务 。 图 3.10 显 示 了 这 
两 个 类 的 作用 和 区 别 。 
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图 3.10 RecursiveAction 和 RecursiveTask 


下 面 我 们 简单 地 展示 Fork/Join 框 染 的 使 用 ， 这 里 用 来 计算 数列 求 
和 。 


01 public class CountTask extends RecursiveTask<Long>{ 


02 private static final int THRESHOLD = 10000; 
03 private long start; 

04 private long end; 

05 

06 public CountTask(long start,long end){ 

07 this.start=start; 


08 this.end=end; 


09 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 
32 
33 
34 
35 


public Long compute(){ 
long sum=0; 
boolean canCompute = (end-start)<THRESHOLD; 
if (canCompute) { 


for(long i=start;i<=end;it+t+){ 


sum +=i; 
} 
yelse{ 
// 分 成 100 个 小 任务 


long step=(start+end)/100; 
ArrayList<CountTask> subTasks=new ArrayList<Coun 
long pos=start; 
for(int i=0;i<100;i++){ 
long lastOne=pos+step; 
if(lastOne>end)lastOne=end; 
CountTask subTask=new CountTask(pos, lastOne); 
pos+=step+1; 
subTasks.add(subTask); 
subTask.fork(); 
} 
for(CountTask t:subTasks){ 


sum+=t.join(); 


h: 


return sum; 


37 

38 public static void main(String[ ]args){ 

39 ForkJoinPool forkJoinPool = new ForkJoinPool(); 
40 CountTask task = new CountTask(0, 20000O0L ) ; 

41 ForkJoinTask<Long> result = forkJoinPool.submit(task) 
42 try{ 

43 long res = result.get(); 

44 System.out.println("sum="+res); 

45 }catch(InterruptedException e){ 

46 e.printStackTrace(); 

47 }catch(ExecutionException e){ 

48 e.printStackTrace(); 

49 } 

50 } 

51 } 


由 于 计算 数列 的 和 必然 是 需要 函数 返回 值 的 ， 因 此 选择 
RecursiveTask 作 为 任务 的 模型 。 上 述 代码 第 39 行 ， 建 立 ForkJoinPool 线 
程 池 。 在 第 40 行 ， 构 造 一 个 计算 1 到 200000 求 和 的 任务 。 在 第 41 行 将 任 
务 提交 给 线程 池 ， 线 程 池 会 返回 一 个 携带 结果 的 任务 ， 通 过 get() 方 法 可 
以 得 到 最 终结 果 BAT) 。 如 果 在 执行 get(0) 方 法 时 ， 任 务 没有 结 
那么 主线 程 就 会 在 get() 方 法 时 等 待 。 








下 面 来 看 一 下 CountTask 的 实现 。 首 先 CountTask 继 承 目 
RecursiveTask， 可 以 携带 返回 值 ， 这 里 的 返回 值 类 型 设置 为 Iong。 第 2 
行 定义 的 THRESHOLD 设 置 了 任务 分 解 的 规模 ， 也 就 是 如 果 需 要 求 和 的 





总 数 大 于 THRESHOLD 人 个， 那么 任务 就 需要 再 次 分 解 ， 人 否则 就 可 以 直接 
执行 。 这 个 判断 逻辑 在 第 14 行 有 体现 。 如 果 任 务 可 以 直接 执行 ， 那 么 直 
接 进行 求 和 ， 返 回 结果 。 否 则 ， 就 对 任务 再 次 分 解 。 每 次 分 解 时 ， 简 单 
地 将 原 有 任务 划分 成 100 个 等 规模 的 小 任务 ， 并 使 用 fork0O 提 交 子 任务 。 
之 后 ， 等 竺 所 有 的 子 任务 结束 ， 并 将 结果 再 次 求 和 《第 31 一 33 行 ) 。 





在 使 用 ForkJoin 时 需要 注意 ， 如 采 任 务 的 划分 层次 很 深 ， 一 直 得 不 
到 返回 ， 那 么 可 能 出 现 两 种 情况 : 第 一 ， 系 统 内 的 线程 数量 越 积 越 多 ， 
导致 性 能 严重 下 降 。 第 二 ， 函 数 的 调用 层次 变 得 很 深 ， 最 终 导致 栈 海 
出 。 不 同 版 本 的 JDK 内 部 实现 机 制 可 能 有 差异 ， 从 而 导致 其 表现 不 同 。 








下 面 的 StackOverflowError 异 常 就 是 加 深 本 例 的 调用 层次 ， 在 JDK 8 
上 得 到 的 错误 。 


java.util.concurrent.ExecutionException: java.lang.StackOverflowE 
at java.util.concurrent.ForkJoinTask.get(ForkJoinTask.java:10 
at geym.conc.ch3.fork.CountTask.main(CountTask.java:51) 


Caused by: java.lang.StackOverflowError 


此 外 ，ForkJoin 线 程 池 使 用 一 个 无 锁 的 栈 来 管理 空闲 线程 。 如 有 果 一 
个 工作 线程 暂时 取 不 到 可 用 的 任务 ， 则 可 能 会 被 挂 起 ， 挂 起 的 线程 将 会 
被 压 入 由 线程 池 维 护 的 栈 中 。 竺 将 来 有 任务 可 用 时 ， 再 从 栈 中 唤醒 这 些 
线程 。 


33 ”不 要 重复 发 明 轮 子 : JDK 的 并 
KEES 


除了 提供 诸如 同步 控制 ， 线 程 池 等 基本 工具 外 ， 为 了 提高 开发 人 员 
的 效率 ，JDK 还 为 大 家 准备 了 一 大 批 好 用 的 容 需 类 ， 可 以 大 大 减少 开发 
工作 量 。 大 家 应 该 都 听 说 过 一 种 说 法 ， 所 谓 程 序 就 是 “算法 + 数据 结 
H, 这 些 容器 类 束 是 为 大 家 准备 好 的 线程 数据 结构 。 你 可 以 在 里 面 找 
到 链表 、HashMap、 队 列 等 。 当 然 ， 它 们 都 是 线程 安全 的 。 








在 这 里 ， 我 也 打算 花 一 些 篇 幅 为 大 家 介绍 一 下 这 些 工 具 类 。 这 些 容 
需 类 的 封闭 都 是 非 闻 完善 并 且 “ 平 易 近 人 ”的 ， 也 就 是 说 只 要 你 有 那么 一 
点 点 的 编程 经 验 ， 就 可 以 非常 容易 地 使 用 这 些 容器 。 因 此 ， 我 可 能 会 花 
更 多 的 时 间 来 分 析 这 些 工具 的 具体 实现 ， 和 希望 起 到 抛砖引玉 的 作用 。 


3.3.1 超 好 用 的 工具 类 : FRERE M 
AN 
J | 











JDK 提 供 的 这 些 容器 大 部 分 在 java.util.concurrent 包 中 。 我 先 提纲 者 
领地 介绍 一 下 它们 ， 初 次 露脸 ， 大 家 只 需要 知道 他 们 的 作用 即 可 。 有 关 
具体 的 实现 和 注意 事项 ， 在 后 面 我 会 慢 慢 道 来 。 





e ConcurrentHashMap: 这 是 一 个 高 效 的 并 发 HashMap。 你 可 以 理 
解 为 一 个 线程 安全 的 HashMap。 
e CopyOnWriteArrayList: 这 是 一 个 List， 从 名 字 看 就 是 和 ArrayList 


是 一 族 的 。 在 读 多 与 少 的 场合 ， 这 个 List 的 性 能 非常 好 ， 远 远 好 
于 Vector。 

ConcurrentLinkedQueue: 高 效 的 并 发 队列 ， 使 用 链表 实现 。 可 以 
看 做 一 个 线程 安全 的 LinkedList。 

BlockingQueue: 这 是 一 个 接口 ，JDK 内 部 通过 链表 、 数 组 等 方式 
实现 了 这 个 接口 。 表 示 阻 塞 队列 ， 非 常 适合 用 于 作为 数据 共享 的 
ConcurrentSkipListMap: 跳 表 的 实现 。 这 是 一 个 Map， 使 用 跳 表 
的 数据 结构 进行 快速 查找。 





除了 以 上 并 发 包 中 的 专 有 数据 结构 外 ，java.util 下 的 Vector 是 线程 安 
全 的 《虽然 性 能 和 上 述 专用 工具 没 得 比 ) ， 另 外 Collections 工 具 类 可 以 
帮助 我 们 将 任意 集合 包装 成 线程 安全 的 集合 。 





3.3.2 ”线程 安全 的 HashMap 


在 之 前 的 章节 中 ， 己 经 给 大 家 展示 了 在 多 线程 环境 中 使 用 HashMap 
所 带 来 的 问题 。 那 如 果 需 要 一 个 线程 安全 的 HashMap 应 该 怎么 做 呢 ? 一 
种 可 行 的 方法 是 使 用 Collections.synchronizedMap0) 方 法 包装 我 们 的 
HashMap。 如 下 代码 ， 产 生 的 HashMap 束 是 线程 安全 的 : 


public static Map m=Collections.synchronizedMap(new HashMap()); 


Collections.synchronizedMap0O 会 生成 一 个 名 为 SynchronizedMap 的 
Map。 它 使 用 委托 ， 将 自己 所 有 Map 相 关 的 功能 交 给 传 入 的 HashMap 实 
现 ， 而 自己 则 主要 负责 保证 线程 安全 。 





有 具体 参考 下 面 的 实现 ， 首 先 SynchronizedMap 内 包装 了 一 个 Map。 


private static class SynchronizedMap<kK,V> 
implements Map<K,V>, Serializable { 


private static final long serialVersionUID = 197819847965 


private final Map<K,V> m; // Backing Map 


final Object mutex; // Object on which to syn 


通过 mnutex 实 现 对 这 个 m 的 互 斥 操作 。 比 如 ， 对 于 Map.get() 方 法 ， 
它 的 实现 如 下 : 


public V get(Object key) { 


synchronized (mutex) {return m.get(key);} 


而 其 他 所 有 相关 的 Map 操 作 都 会 使 用 这 个 mutex 进 行 同 步 。 从 而 实 
现 线程 安全 。 


这 个 包装 的 Map 可 以 满足 线程 安全 的 要 求 。 但 是 ， 它 在 多 线程 环境 
中 的 性 能 表现 并 不 算 太 好 。 无 论 是 对 Map 的 读 取 或 者 写 入 ， 都 需要 获得 
mutex 的 锁 ， 这 会 导致 所 有 对 Map 的 操作 全 部 进入 等 竺 状态， 直到 mutex 
锁 可 用 。 如 果 并 发 级 别 不 高 ， 一 般 也 够 用 。 但 是 ， 在 高 并 发 环境 中 ， 我 
们 也 有 必要 寻求 新 的 解决 方案 。 

一 个 更 加 专业 的 并 发 HashMap 是 ConcurrentHashMap。 它 位 于 


java.util.concurrent 包 内 。 它 专门 为 并 发 进行 了 性 能 优化 ， 因 此 ， 更 加 适 
合 多 线程 的 场合 。 


有 关 ConcurrentHashMap 的 具体 实现 细节 ， 大 家 可 以 参考 “第 4 章 锁 
的 优化 及 注意 事项 ”一 章 。 我 们 将 在 那里 给 出 更 加 详细 的 实现 说 明 。 


3.3.3 ”有关 List 的 线程 安全 


以 列 、 链 表 之 类 的 数据 结构 也 是 极其 常用 的 ， 几 乎 所 有 的 应 用 程序 
都 会 与 之 相关 。 在 Java 中 ，ArrayList 和 Vector 都 是 使 用 数组 作为 其 内 部 
实现 。 两 者 最 大 的 不 同 在 于 Vector 是 线程 安全 的 ， 而 ArrayList 不 是 。 此 
外 ，LinkedList 使 用 链表 的 数据 结构 实现 了 List。 但 是 很 不 邓 ， 
LinkedList 并 不 是 线程 安全 的 ， 不 过 参考 前 面 对 HashMap 的 包装 ， 在 这 
里 我 们 也 可 以 使 用 Collections.synchronizedList(O) 方 法 来 包装 任意 List， 如 
下 所 示 : 








public static List<String> 1=Collections.synchronizedList(new Li 


此 时 生成 的 List 对 象 就 是 线程 安全 的 。 


3.3.4 mi ME SINKS: REHAT 
ConcurrentLinkedQueue 


以 列 Queue 也 是 常用 的 数据 结构 之 一 。 在 JDK 中 提供 了 一 个 
ConcurrentLinkedQueue 类 用 来 实现 高 并 发 的 队列 。 从 名 字 可 以 看 到 ， 这 
个 队列 使 用 链表 作为 其 数据 结构 。 有 关 ConcurrentLinkedQueue 的 性 能 测 
试 ， 大 家 可 以 自行 答 试 。 这 里 限于 篇 幅 就 不 再 给 出 性 能 测试 的 代码 。 大 
家 只 要 知道 ConcurrentLinkedQueue 应 该 算是 在 高 并 发 环境 中 性 能 最 好 的 
队列 就 可 以 了 。 它 之 所 有 能 有 很 好 的 性 能 ， 是 因为 其 内 部 复杂 的 实现 。 























在 这 里 ， 我 更 加 愿意 花 一 些 篇 幅 来 简单 介绍 一 下 
ConcurrentLinkedQueue 的 具体 实现 细节 。 不 过 在 深 入 





ConcurrentLinkedQueue 之 前 ， 我 强烈 建议 大 家 先 阅读 一 下 第 4 章 ， 补 充 


一 下 有 关 无 锁 操 作 的 一 些 知识 。 





作为 一 个 链表 ， 目 然 需要 定义 有 关 链 表 内 的 节点 ， 在 
ConcurrentLinkedQueue 中 ， 和 定义 的 节点 Node 核 心 如 下 : 


private static class Node<E> { 
volatile E item; 


volatile Node<E> next; 








其 中 item 是 用 来 表示 目标 元 系 的 。 比 如 ， 当 列表 中 存放 String 时 ， 
这 样 每 个 





item 束 是 String 类 型 。 字 上 段 next 表 示 当 前 Node 的 下 一 个 元 素 ， 
Node 束 能 环 环 相 扣 ， 串 在 一 起 了 。 如 图 3.11 所 示 ， 显 示 了 
ConcurrentLinkedQueue 的 基本 结构 。 


ConcurrentLinkedQueue es 


offer() item 
poll() next 


图 3. 11 ConcurrentLinkedQueue # # 24 44 


对 Node 进 行 操作 时 ， 使 用 了 CAS 操 作 。 


boolean casItem(E cmp, E val) { 


return UNSAFE.compareAndSwapObject(this, itemOffset, 


cmp, 


val 


void lazySetNext(Node<E> val) { 


UNSAFE. putOrderedObject(this, nextOffset, val); 


boolean casNext(Node<E> cmp, Node<E> val) { 


return UNSAFE.compareAndSwapObject(this, nextOffset, cmp, val 


方法 casltem() 表 示 设 置 当 前 Node 的 item 值 。 它 需要 两 个 参数 ， 第 一 
个 参数 为 期 望 值 ， 第 二 个 参数 为 设置 目标 值 。 当 当前 值 等 于 cmp 期 望 值 
时 ， 就 会 将 目标 设置 为 val。 同 样 casItem(0 方 法 也 是 类 似 的 ， 但 是 它 是 用 
来 设置 next 字 段 ， 而 不 是 item 字 段 。 











ConcurrentLinkedQueue 内 部 有 两 个 重要 的 字段 ，head 和 tail， 分 别 表 
示 链 表 的 头 部 和 尾部 ， 它 们 都 是 Node 类 型 。 对 于 head 来 说 ， 它 永远 不 会 
为 null， 并 且 通 过 head 以 及 succ0 后 继 方 法 一 定 能 完整 地 遍历 整个 链表 。 
对 于 tail 来 说 ， 它 自然 应 该 表示 队列 的 末尾 。 











但 ConcurrentLinkedQueue 的 内 部 实现 非常 复杂 ， 它 允许 在 运行 时 链 
表 处 于 多 个 不 同 的 状态 。 以 tai 为 例 ， 一 般 来 说， 我 们 期 望 tail 总 是 为 链 
表 的 末尾 ， 但 实际 上 ，tail 的 更 新 并 不 是 及 时 的 ， 而 是 可 能 会 产生 拖延 
现象 。 如 图 3.12 所 示 ， 显 示 了 插入 时 ，tail 的 更 新 情况 ， 可 以 看 到 tail 的 
更 新 会 产生 滞后 ， 并 且 每 次 更 新 会 跳跃 两 个 元 素 。 
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图 3. 12 GAD aittai la & af 





可 以 看 到 tail 并 不 总 是 在 更 新 。 下 和 面 就 是 ConcurrentLinkedQueue 中 
同 队 列 中 添加 元 素 的 offer0 方 法 (本 节 中 使 用 JDK 7u40 的 代码 ， 不 同 版 
本 的 代码 可 能 存在 差异 ) : 





01 public boolean offer(E e) { 


02 checkNotNull(e); 

03 final Node<E> newNode = new Node<E> (e); 
04 

05 for (Node<E> t = tail, p=t;;) { 

06 Node<E> q = p.next; 

07 if (q == null) { 

08 // p 是 最 后 一 个 节点 

09 if (p.casNext(null, newNode)) { 


10 // 每 2 次 ， 更 新 一 下 tail 


11 if (p != t) 





12 casTail(t, newNode); 

13 return true; 

14 } 

15 //CAS 竞 争 失败 ， 再 次 党 试 

16 } 

17 else if (p == q) 

18 // 遇 到 哨兵 节点 ， 从 都 head 开始 壳 历 。 

19 // 但 如 果 tail 被 修改 ， 则 使 用 tail (因为 可 能 被 修改 正确 了 ) 
20 p= (t != (t = tail)) ? t : head; 

21 else 

22 // 取 下 一 个 节点 或 者 最 后 一 个 节点 

23 p = (p !=t && t != (t = tail)) ? t : q; 
24 } 

25 } 








首先 值得 注意 的 是 ， 这 个 方法 没有 任何 锁 操 作 。 线 程 安全 完全 由 
CAS 操 作 和 队列 的 算法 来 保证 。 整 个 方法 的 核心 是 for 循 环 ， 这 个 循环 没 
有 出 口 ， 直 到 尝试 成 功 ， 这 也 符合 CAS 操 作 的 流程 。 当 第 一 次 加 入 元 素 
时 ， 由 于 队列 为 空 ， 因 此 p.next 为 null。 程 序 进 入 第 8 行 。 并 将 p 的 next 节 
点 赋值 为 newNode， 也 就 是 将 新 的 元 素 加 入 到 队列 中 。 此 时 p==t 成 世 ， 
因此 不 会 执行 第 12 行 的 代码 更 新 tail 末 尾 。 如 果 casNext(0) 成 功 ， 程 序 直 接 
返回 ， 如 果 失 败 ， 则 再 进行 一 次 循环 尝试 ， 直 到 成 功 。 因 此 ， 增 加 一 个 
元 素 后 ，tail 并 不 会 被 更 新 。 





当 程 序 试图 增加 第 2 个 元 素 时 ， 由 于 t 还 在 head 的 位 置 上 ， 因 此 p.next 
指 癌 实际 的 第 一 个 元 素 ， 因 此 第 6 行 的 q!=nul， 这 表示 g 不 是 最 后 的 节 








扩 。 由 于 往 队 列 中 增加 元 素 需 要 最 后 一 个 节操 的 位 置 ， 因 此 ， 循 环 开始 
查找 最 后 一 个 市 反 。 于 是 ， 程 序 会 进入 第 23 行 ， 获 得 最 后 一 个 市 点 。 此 
时 ，p 实 际 上 古 指 癌 链表 中 的 第 一 个 元 素 ， 而 它 的 next 为 null， 故 在 第 2 
个 循环 时 ， 进 入 第 8 行 。p 更 新 自己 的 next， 让 它 指向 新 加 入 的 节点 。 如 
果 成 功 ， 由 于 此 时 p!=t 成 功 ， 则 会 更 新 t 所 在 位 置 ， 将 {移动 到 链表 最 
后 。 








在 第 17 行 ， 处 理 了 p==qg 的 情况 。 这 种 情况 是 由 于 过 到 了 哨兵 

(sentinel) 市 点 导致 的 。 所 谓 哨兵 节点 ， 束 是 next 指 同 自 己 的 节点 。 这 
种 节点 在 队列 中 的 存在 价值 不 大 ， 主 要 表示 要 删除 的 节点 ， 或 者 空 市 
点 。 当 遇 到 哨兵 节点 时 ， 由 于 无 法 通过 next 取 得 后 续 的 节点 ， 因 此 很 可 
能 直接 返回 head， 期 望 通过 从 链表 头 部 开始 衣 历 ， 进 一 步 查 找到 链表 末 
尾 。 但 一 旦 发 生 在 执行 过 程 中 ，tail 被 其 他 线程 修改 的 情况 ， 则 进行 一 
次 “打赌 ?， 使 用 新 的 tail 作 为 链表 末尾 〈 这 样 就 避免 了 重新 得 找 tail 的 开 
销 ) 。 








如 果 大 家 对 Java 不 是 特别 就 悉 ， 可 能 会 对 类 似 下 面 的 代码 产生 疑惑 
(第 20 行 ) : 


Doe (r HS (r = Gael) 7 e head: 





这 人 句 代码 虽然 只 有 短 短 一 行 ， 但 是 包含 的 信息 比较 多 。 首 先 “!=” 并 
不 是 原子 操作 ， 它 是 可 以 被 中 断 的。 也 就 是 说 ， 在 执行 “5=? 是 ， 程 序 会 
先 取 得 t 的 值 ， 再 执行 t=tail， 并 取得 新 的 t 的 值 。 然 后 比较 这 两 个 值 是 否 
相等 。 在 单线 程 时 ，t!=t 这 种 语句 显然 不 会 成 并 。 但 是 在 并 发 环境 中 ， 
有 可 能 在 获得 左边 的 t 值 后 ， 右 边 的 t 值 被 其 他 线程 修改 。 这 样 ，t!=t 就 可 
能 成 立 。 这 里 就 是 这 种 情况 。 如 果 在 比较 过 程 中 ，tail 被 其 他 线程 修 
改 ， 当 它 再 次 赋值 给 t 时 ， 就 会 叶 致 等 式 左边 的 t 和 右边 的 t 不 同 。 如 果 两 











个 t 不 相同 ， 表 示 tail 在 中 途 被 其 他 线程 咎 改 。 这 时 ， 我 们 就 可 以 用 新 的 
tail 作 为 链表 末尾 ， 也 就 是 这 里 等 式 右边 的 t。 但 如 果 tail 没 有 被 修改 ， 则 
返回 head， 要 求 从 头 部 开始 ， 重 新 碍 找 尾部 。 





作为 简化 问题 ， 我 们 考察 t!=t 的 字 节 码 ( 注 意 这 里 假设 t 为 静态 整形 


11: getstatic #10 // Field t:I 
14: getstatic #10 // Field t:I 
17: if_icmpeq 24 


可 以 看 到 ， 在 字 节 码 层 面 ，t 被 先后 取 了 两 次 ， 在 多 线程 环境 下 ， 
我 们 自然 无 法 保证 两 次 对 t 的 取 值 会 是 相同 的 ， 如 图 3.13 所 示 ， 显 示 了 这 
种 情况 。 
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图 3. 13 tl!=t 成 立 的 情况 


下 面 我 们 来 看 一 下 哨兵 市 点 是 如 何 产生 的 : 


ConcurrentLinkedQueue<String> q=new ConcurrentLinkedQueue<Strin 


q.add("1"); 
q.poll(); 


EXAMS 347, RENIER. HAITIEN F: 


01 public E poll() { 


02 restartFromHead: 

03 POR CPPI E 

04 for (Node<E> h = head, p = h, q;;) { 

05 E item = p.item; 

06 if (item != null && p.casItem(item, null)) { 
07 if (p != h) 

08 updateHead(h, ((q = p.next) != null) ? q : 
09 return item; 

10 } 

11 else if ((q = p.next) == null) { 

12 updateHead(h, p); 

13 return null; 

14 } 

15 else if (p == q) 

16 continue restartFromHead; 

17 else 

18 p= q, 

19 } 

20 } 

21 } 


由 于 队列 中 只 有 一 个 元 素 ， 根 据 前 文 的 描述 ， 此 时 tail 并 没有 更 


新 ， 而 是 指 同 和 head 相 同 的 位 置 。 而 此 时 ，head 本 里 的 item 域 为 mull， 其 
next 为 列表 第 一 个 元 素 。 故 在 第 一 个 循环 中 ， 代 码 直 接 进 入 第 18 行 ， 将 
p 赋 值 为 g9， 而 q 就 是 p.next， 也 是 当前 列表 中 的 第 一 个 元 素 。 接 着 ， 在 第 
2 轮 循环 中 ，p.item 显 然 不 为 null (为 字符 串 1) 。 因 此 ， 代 码 应 该 可 以 顺 
利 进 入 第 7 行 《 如 果 CAS 操 作成 功 ) 。 进 入 第 7 行 ， 也 意味 着 p 的 item 域 

被 设置 为 nul《〈 因 为 这 是 弹出 元 素 ， 上 自然 需要 删除 ) 。 同 时 ， 此 时 p 和 h 
是 不 相等 的 (因为 p 已 经 指 同 原 有 的 第 一 个 元 素 了 ) 。 故 执行 了 第 8 行 的 
updateHead() 操 作 ， 其 实现 如 下 : 





final void updateHead(Node<E> h, Node<E> p) { 
if (h != p && casHead(h, p)) 
h.lazySetNext(h); 


可 以 看 到 ， 在 updateHead 中 ， 就 将 p 作 为 新 的 链表 头 部 〈 通 过 
casHead() 实 现 ) ， 而 原 有 的 head 就 被 设置 为 哨兵 (通过 lazySetNext() 实 
现 ) 。 


这 样 一 个 噶 兵 市 点 残 产 生 了 ， 而 由 于 此 时 原 有 的 head 头 部 和 tail 实 际 
上 是 同一 个 元 素 。 因 此 ， 再 次 offer() 插 入 元 素 时 ， 就 会 过 到 这 个 tail， 也 
就 是 哨兵 。 这 惑 是 offerO 代 码 中 ， 第 17 行 的 判断 的 意义 。 





通过 这 些 说 明 ， 大 家 应 该 可 以 明显 感觉 到 ， 不 使 用 锁 而 单纯 地 使 用 
CAS 操 作 会 要 求 在 应 用 层面 保证 线程 安全 ， 并 处 理 一 些 可 能 存在 的 不 一 
致 问题 ， 大 大 增加 了 程序 设计 和 实现 的 难度 。 但 是 它 带 来 的 好 处 就 是 可 
以 得 到 性 能 的 飞速 提升 。 因 此 ， 在 有 些 场合 也 是 值得 的 。 


3.3.5 高效 读 取 : 不 变 模式 下 的 
CopyOnwWriteArrayList 


在 很 多 应 用 场景 中 ， 读 操作 可 能 会 远 远大 于 写 操 作 。 比 如 ， 有 些 系 
统 级 别 的 信息 ， 往 往 只 需要 加 载 或 者 修改 很 少 的 次 数 ， 但 是 会 被 系统 内 
所 有 模块 频 蚂 的 访问 。 对 于 这 种 场景 ， 我 们 最 希望 看 到 的 束 是 读 操作 可 
以 尽 可 能 地 快 ， 而 写 即 使 慢 一 些 也 没有 太 大 关系 。 


由 于 读 操 作 根 本 不 会 修改 原 有 的 数据 ， 因 此 对 于 每 次 读 取 都 进行 加 
锁 其 实 是 一 种 资源 浪费 。 我 们 应 该 允许 多 个 线程 同时 访问 List 的 内 部 数 
据 ， 毕 竟 读 取 操 作 是 安全 的 。 根 据 读 写 锁 的 思想 ， 读 锁 和 读 锁 之 间 确 实 
也 不 神 突 。 但 是 ， 读 操作 会 受到 写 操作 的 阻碍 ， 当 写 及 生 时 ， 读 就 必须 
等 待 ， 否 则 可 能 读 到 不 一 致 的 数据 。 同 理 ， 如 果 读 操作 正在 进行 ， 程 序 
也 不 能 进行 号 入 。 


为 了 将 读 取 的 性 能 发 挥 到 极致 ，JDK 中 提供 了 
CopyOnWriteArrayList 类 。 对 它 来 说 ， 读 取 是 完全 不 用 加 锁 的 ， 并 且 更 
好 的 消息 是 : 写 入 也 不 会 阻塞 读 取 操作 。 只 有 写 入 和 写 入 之 间 需 要 进行 
同步 等 待 。 这 样 一 来 ， 读 操作 的 性 能 就 会 大 幅度 提升 。 那 它 是 怎么 做 的 
呢 ? 


从 这 个 类 的 名 字 我 们 可 以 看 到 ， 所 谓 CopyOnWrite 就 是 在 写 入 操作 
时 ， 进 行 一 次 自我 复制 。 换 句 话说， 当 这 个 List 需 要 修改 时 ， 我 并 不 修 
改 原 有 的 内 容 《〈 这 对 于 保证 当前 在 读 线程 的 数据 一 致 性 非常 重要 ) ， 而 
是 对 原 有 的 数据 进行 一 次 复制 ， 将 修改 的 内 容 写 入 副本 中 。 写 完 之 后 ， 
再 将 修改 完 的 副本 蔡 换 原来 的 数据 。 这 样 就 可 以 保证 写 操作 不 会 影响 读 
hs 


下 面 的 代码 展示 了 有 关 读 取 的 实现 : 


private volatile transient Object[] array; 
public E get(int index) { 
return get(getArray(), index); 
} 
final Object[] getArray() { 
return array; 
} 
private E get(Object[] a, int index) { 


return (E) a[index]; 


需要 注意 的 是 : 读 取 代码 没有 任何 同步 控制 和 锁 操 作 ， 理 由 就 是 内 
部 数组 array 不 会 发 生 修改 ， 只 会 被 另外 一 个 array 蔡 换 ， 因 此 可 以 保证 数 
据 安 全 。 大 家 也 可 以 参考 “5.2 不 变 模式 ”一 节 ， 相 信 可 以 有 更 深 的 认识 。 


和 简单 的 读 取 相 比 ， 写 入 操作 束 有 些 麻 烦 了 : 


01 public boolean add(E e) { 


02 final ReentrantLock lock = this.lock; 

03 lock.lock(); 

04 try { 

05 Object[] elements = getArray(); 

06 int len = elements.length; 

07 Object[] newElements = Arrays.copyOf(elements, len + 1 
08 newElements[len] = e; 


09 setArray(newElements); 


10 return true; 


11 } finally { 
12 lock.unlock(); 
13 } 
14 } 
首先 ， 写 入 操作 使 用 锁 ， 当 然 这 个 锁 仅 限于 控制 号 - 写 的 情况 。 其 








重点 在 于 第 7 行 代码 ， 进 行 了 内 部 元 素 的 完整 复制 。 因 此 ， 会 生成 一 个 
新 的 数组 newElements。 然 后 ， 将 新 的 元 素 加 入 newElements。 接 着 ， 在 
第 9 行 ， 使 用 新 的 数组 蔡 换 老 的 数组 ， 修 改 束 完成 了 。 整 个 过 程 不 会 影 
啊 恋 取 ， 并 且 修 改 完 后 ， 读 取 线 程 可 以 立即 “察觉 ?到 这 个 修改 《因为 


array 变 量 是 volatile 类 型 ) 。 


3.3.6 ”数据 共享 通道 BlockingQueue 


前 文中 ， 我 们 已 经 提 到 了 ConcurrentLinkedQueue 作 为 高 性 能 的 队 
列 。 对 于 并 发 程序 而 言 ， 高 性 能 自然 是 一 个 我 们 需要 追求 的 目标 。 但 多 
线程 的 开发 模式 还 会 引入 一 个 问题 ， 那 就 是 如 何 进 行 多 个 线程 间 的 数据 
共享 呢 ? 比如， 线程 A 希望 给 线程 B 发 一 个 消息 ， 用 什么 方式 告知 线程 B 
是 比较 合理 的 呢 ? 














一 般 来 说， 我 们 总 是 硕 望 整个 系统 是 松散 耘 合 的 。 比 如 ， 你 所 在 小 
区 的 物业 和 希望 可 以 得 到 一 些 业 主 的 意见 ， 设 立 了 一 个 意见 箱 ， 如 有 果 对 物 
业 有 任何 要 求 和 或 者 意见 都 可 以 投 到 意见 箱 里 。 这 时 ， 作 为 业主 的 你 并 
不 需要 直接 找到 物业 相关 的 领导 表达 你 的 意见 。 实 际 上 ， 物 业 的 工作 人 
员 也 可 能 经 党 发 生变 动 ， 直 接 找 工作 人 员 未 必 是 一 件 方便 的 事情 。 而 你 
投递 到 意见 箱 的 意见 总 是 会 被 物业 的 工作 人 员 看 到 ， 不 管 是 否 及 生 了 人 























员 的 变动 。 这 样 ， 你 就 可 以 很 容易 地 表达 自己 的 诉求 了 。 你 既 不 需要 直 
接 和 他 们 对 话 ， 又 可 以 轻松 提出 自己 的 建议 (这 里 假定 我 们 物业 公司 的 
员工 都 是 尽心 尽责 的 好 员工 ) 。 





将 这 个 模式 映射 到 我 们 程序 中 。 就 是 说 我 们 既而 望 线程 A 能 够 通知 
线程 B， 又 希望 线程 A 不 知道 线程 B 的 存在 。 这 样 ， 如 果 将 来 进行 重 构 或 
者 升级 ， 我 们 完全 可 以 不 修改 线程 A， 而 直接 把 线程 B 升 级 为 线程 C， 保 
证 系统 的 平滑 过 渡 。 而 这 中 间 的 “意见 箱 ? 束 可 以 使 用 BlockingQueue 来 实 
现 。 








与 之 前 提 到 的 ConcurrentLinkedQueue 或 者 CopyOnWriteArrayList 不 
同 ， A a N 口 ， 并 非 一 个 具体 的 实现 。 它 的 主要 实现 
有 下 面 一 些 ， 如 图 3.14 所 示 。 





- java. util. concurrent 





a 9 Blockinglorae E> 
ArrayBlockingQueue<E> - java. util. concurrent 
Qs DelayedWorkQueue - java. util. concurrent. ScheduledThr: 
(C) DelayQueue<E> - java. util. concurrent 
+ © LinkedBlockingQueue<E> - java. util. concurrent 
PriorityBlockingQueue<E> - java. util. concurrent 
Synchr onousQueue<E> - java. util. concurrent 
BlockingDeque<E> - java. util. concurrent 





©0000 


+ 


图 3-14 BlockingQueue 的 主要 实现 


这 里 我 们 主要 介绍 ArrayBlockingQueue 和 LinkedBlockingQueue。 从 
名 字 应 该 可 以 得 知 ，ArrayBlockingQueue 是 基于 数组 实现 的 ， 而 
LinkedBlockingQueue 基 于 链表 。 也 正 因 为 如 此 ，ArrayBlockingQueue 更 
适合 做 有 界 队 列 ， 因 为 队列 中 可 容纳 的 最 大 元 又 需要 在 队列 创建 时 指定 
《毕竟 数组 的 动态 扩展 不 太 方便 ) 。 而 LinkedBlockingQueue 适 合 做 无 界 
队列 ， 或 者 那些 边界 值 非常 大 的 队列 ， 因 为 其 内 部 元 兹 可 以 动态 增加 ， 














它 不 会 因为 初 值 容量 很 大 ， 而 一 口气 吃 挥 你 一 大 半 的 内 存 。 


而 BlockingQueue 之 所 有 适合 作为 数据 共享 的 通道 ， 其 关键 还 在 于 
Blocking 上 。Blocking 是 阻塞 的 意思 ， 当 服务 线程 〈 服 务 线程 指 不 断 获 
取 队 列 中 的 消息 ， 进 行 处 理 的 线程 ) 处 理 完 成 队列 中 所 有 的 消息 后 ， 它 
如 何 知 道 下 一 条 消 恩 何 时 a 到 来 呢 ? 








一 种 最 傻瓜 化 的 做 法 是 让 这 个 线程 按照 一 定 的 时 间 间 隔 不 停 地 循环 
和 监控 这 个 队列 。 这 是 可 行 的 一 种 方案 ,但 显然 造成 了 不 必要 的 资源 浪 
费 ， 而 循环 周期 也 难以 确定 。 而 BlockingQueue 很 好 地 解决 了 这 个 问 
题 。 它 会 让 服务 线程 在 队列 为 空 时 ， 进 行 等 等 ， 当 有 新 的 消息 进入 队列 
后 ， 自 动 将 线程 唤醒 ， 如 图 3.15 所 示 。 那 它 是 如 何 实现 的 呢 ?” 我 们 以 
ArrayBlockingQueue 为 例 ， 来 一 探究 竟 。 


Ze) 


全 
eB 
) , Z 
AIWF 4 4 

图 3.15 BlockingQueue 的 工作 模式 


ArrayBlockingQueue 的 内 部 元 素 都 放置 在 一 个 对 象 数组 中 : 


final Object[] items; 


向 队列 中 压 入 元 素 可 以 使 用 offer0 方 法 和 put0) 方 法 。 对 于 offer() 方 
法 ， 如 采 当 前 队列 已 经 满 了 ， 它 就 会 立即 返回 false。 如 果 没 有 满 ， 则 执 
行 正 常 的 入 队 操 作 。 所 以 ， 我 们 不 讨论 这 个 方法 。 现 在 ， 我 们 需要 关注 
的 是 put0 方 法 。put(0 方 法 也 是 将 元 兹 压 入 队列 末尾 。 但 如 果 队 列 满 了 ， 
它 会 一 直 等 待 ， 直 到 队列 中 有 空闲 的 位 置 。 





从 队列 中 弹出 元 素 可 以 使 用 poll0 方 法 和 take0 方 法 。 它 们 都 从 队列 


的 头 部 获得 一 个 元 素 。 不 同 之 处 在 于 : 如 果 队 列 为 空 poll(0 方 法 直接 返 
回 null， 而 take(0) 方 法 会 等 待 ， 直 到 队列 内 有 可 用 元 素 。 


因此 ，put0 方 法 和 take() 方 法 才 是 体现 Blocking 的 关键 。 为 了 做 好 等 
待 和 通知 两 件 事 ， 在 ArrayBlockingQueue 内 部 定义 了 以 下 一 些 字段 : 





final ReentrantLock lock; 
private final Condition notEmpty; 


private final Condition notFull; 


当 执 行 takeO 操 作 时 ， 如 果 队 列 为 室 ， 则 让 当前 线程 等 待 在 
notEmpty 上 。 新 元 素 入 队 时 ， 则 进行 一 次 notEmpty 上 的 通知 。 


下 面 的 代码 显示 了 take0 的 过 程 : 


01 public E take() throws InterruptedException { 


02 final ReentrantLock lock = this.lock; 
03 lock. lockInterruptibly(); 

04 try { 

05 while (count == 0) 

06 notEmpty.await(); 

07 return extract(); 

08 } finally { 

09 lock.unlock(); 

10 } 

11 } 
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private void insert(E x) { 
items[putIndex] = x; 
putIndex = inc(putIndex); 
++count; 


notEmpty.signal(); 
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注意 第 5 行 代 码 ， 当 新 元 系 进 入 队列 后 ， 需 要 通知 等 得 在 notEmpty 
上 的 线程 ， 让 他 们 继续 工作 。 


同 理 ， 对 于 putO 操 作 也 是 一 样 的 ， 当 队列 满 时 ， 需 要 让 压 入 线程 等 
符 ， 如 下 面 第 7 行 。 


01 public void put(E e) throws InterruptedException { 


02 checkNotNull(e); 

03 final ReentrantLock lock = this.lock; 
04 lock.lockIinterruptibly(); 

05 Cryst 

06 while (count == items.length) 
07 notFull.await(); 

08 insert(e); 

09 } finally { 

10 lock.unlock(); 

11 } 

12 } 


当 有 元 素 从 队列 中 被 挪 走 ， 队 列 中 出 现 空位 时 ， 目 然 也 需要 通知 等 
竺 入 队 的 线程 : 


1 private E extract() { 

2 final Object[] items = this.items; 

3 E x = this.<E>cast(items[takeIndex]); 
4 items[takeIndex] = null; 

5 takeIndex = inc(takeIndex); 

6 --count; 

7 notFull.signal(); 

8 return x; 

9 } 


上 述 代 码 表示 从 队列 中 拿 走 一 个 元 素 。 当 有 空闲 位 置 时 ， 在 第 7 
行 ， 通 知 等 竺 入 队 的 线程 。 





BlockingQueue 的 使 用 非常 普遍 。 在 后 续 的 “5.3 生 产 者 消费 者 ”一 节 
中 ， 我 们 还 会 看 到 他 们 的 映 影 。 在 那里 ， 我 们 可 以 更 清楚 地 看 到 如 何 使 
用 BlockingQueue 解 耦 生产 者 和 消费 者 。 


3.3.7 ”随机 数据 结构 跳 表 
(SkipList ) 


在 JDK 的 并 发 包 中 ， 除 了 和 常用 的 哈 希 表 外 ， 还 实现 了 一 种 有 趣 的 数 
所 结构 一 一 跳 表 。 跳 表 是 一 种 可 以 用 来 快速 查找 的 数据 结构 ， 有 点 类 似 
于 平衡 树 。 它 们 都 可 以 对 元 系 进 行 快速 的 查找 。 但 一 个 重要 的 区 别 古 : 
对 平衡 树 的 插入 和 删除 往往 很 可 能 导致 平衡 树 进行 一 次 全 局 的 调整 。 而 
对 跳 表 的 插入 和 删除 只 需要 对 整个 数据 结构 的 局 部 进行 操作 即 可 。 这 样 
市 来 的 好 处 是 : 在 高 并 发 的 情况 下 ， 你 会 需要 一 个 全 局 锁 来 保证 整个 平 




















衡 树 的 线程 安全 。 而 对 于 跳 表 ， 你 只 需要 部 分 锁 即 可 。 ale 在 高 并 发 
环境 下 ， 你 就 可 以 拥有 更 好 的 性 能 询 的 性 能 而 言 ， 跳 表 的 时 间 
复杂 上 度 也 是 O(log m。 所 以 在 并 发 数据 结构 中 ，JDK 使 用 跳 表 来 实现 一 
个 Map。 





跳 表 的 另外 一 个 特点 是 随机 算法 。 跳 表 的 本 质 是 同时 维护 了 多 个 链 
表 ， 并 且 链 表 是 分 层 的 ， 如 图 3.16 所 示 。 
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图 3.16 跳 表 结构 示意 图 








最 低层 的 链表 维护 了 跳 表 内 所 有 的 元 系 ， 每 上 和 面 一 层 链 表 都 是 下 面 
一 层 的 子 集 ， 一 个 元 素 插 入 哪些 层 是 完全 随机 的 。 因 此 ， Cana 
好 的 话 ， 你 可 能 会 得 到 一 个 性 能 很 糟糕 的 结构 。 但 是 在 实际 工作 中 ， 
的 表现 是 非常 好 的 。 








跳 表 内 的 所 有 链表 的 元 系 部 是 排序 的 。 查 找 时 ， 可 以 从 顶级 链表 开 
始 找 。 一 旦 友 现 被 查找 的 元 素 大 于 当前 链表 中 的 取 值 ， 束 会 转 入 下 一 层 
链表 继续 找 。 这 也 束 是 说 在 查找 过 程 中 ， 搜 索 是 跳跃 式 的 ， 如 图 3.17 所 
示 ， 在 跳 表 中 会 找 元 系 7。 会 找 从 顶层 的 头 部 索引 节点 开始 。 由 于 顶层 
的 元 系 最 少 ， 因 此 ， 可 以 快速 跳跃 那些 小 于 7 的 元 素 。 很 快 ， 碍 找 过 程 
就 能 到 元 素 6。 由 于 在 第 2 层 ， 元 素 8 大 于 7， 故 肯定 无 法 在 第 2 层 找到 元 
素 7， 故 直接 进入 底层 〈 包 舍 所 有 元 素 ) 开始 查找 ， 并 且 很 快 就 可 以 根 
据 元 系 6 搜 索 到 元 系 7。 整 个 过 程 ， 要 比 一 般 链 表 从 元 素 1 开 始 逐 个 搜索 
快 很 多 。 
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A3.17 跳 表 的 查找 过 程 


因此 ， 很 显然 ， 跳 表 是 一 种 使 用 空间 换 时 间 的 算法 。 


使 用 跳 表 实现 Map 和 使 用 哈 厦 算法 实现 Map 的 为 外 一 个 不 同 之 处 
wer 哈 布 并 不 会 保存 元 素 的 顺序 ， 而 跳 表 内 所 有 的 元 系 痢 是 排序 的 。 
此 在 对 路 表 进 行 届 历时 ， 你 会 得 到 一 个 有 序 的 结果 。 所 以 ， 如 果 你 的 应 
用 需要 有 序 性 ， 那 么 跳 表 就 是 你 不 二 的 选择 。 

















实现 这 一 数据 结构 的 类 是 ConcurrentSkipListMap。 下 面 展示 了 跳 表 
的 简单 使 用 : 


Map<Integer, Integer> map=new ConcurrentSkipListMap<Integer, In 
for(int 1=0;1<30;1i++){ 
map.put(i,i); 
i 
for(Map.Entry<Integer, Integer> entry:map.entrySet()){ 


System.out.printin(entry.getKey()); 


和 HashMap 不 同 ， 对 跳 表 的 遍历 输出 是 有 序 的 。 





跳 表 的 内 部 实现 有 几 个 关键 的 数据 结构 组 成 。 首 先是 Node， 一 个 
Node 就 是 表示 一 个 节点 ， 里 面 含有 两 个 重要 的 元 素 Key 和 和 value( 束 是 





Map 的 key 和 value) 。 每 个 Node 还 会 指 癌 下 一 个 Node， 因 此 还 有 一 个 元 
素 next。 


static final class Node<kK,V> { 
final K key; 
volatile Object value; 


volatile Node<K,V> next; 


对 Node 的 所 有 操作 ， 使 用 的 CAS 方 法 : 


boolean casValue(Object cmp, Object val) { 


return UNSAFE.compareAndSwapObject(this, valueOffset, cmp, v 


boolean casNext(Node<K,V> cmp, Node<kK,V> val) { 


return UNSAFE.compareAndSwapObject(this, nextOffset, cmp, va 


方法 casValue0) 用 来 设置 value 的 值 ， 相 对 的 casNextO 用 来 设置 next 的 
字段 。 


另外 一 个 重要 的 数据 结构 是 mdex。 顾 名 思 义 ， 这 个 表示 索引 
内 部 包装 了 Node， 同 时 增加 了 加 下 的 引用 和 辐 右 的 引用 。 





> 
o 已 


static class Index<kK,V> { 
final Node<K,V> node; 
final Index<kK,V> down; 


volatile Index<K,V> right; 


整个 跳 表 就 是 根据 Index 进行 全 网 的 组 织 的 。 





此 外 ， 对 于 每 一 层 的 表 头 ， 还 需要 记录 当前 处 于 哪 一 层 。 为 此 ， 还 
需要 一 个 称 为 HeadIndex 的 数据 结构 ， 表 示 链 表 头 部 的 第 一 个 mdex。 它 
继承 目 Index。 





static final class HeadIndex<K,V> extends Index<K,V> { 
final int level; 
HeadIndex(Node<K,V> node, Index<KkK,V> down, Index<K,V> rig 
super(node, down, right); 


this.level = level; 


} 
} 
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织 好 这 些 Index 之 间 的 连接 关系 。 


3.4 ”参考 资料 


。 这 篇 博客 讲解 了 ScheduledThreadPoolExecutor 的 使 用 注意 事项 
o http://segmentfault.com/a/1190000000371905 
。 这 里 讲解 了 几 个 有 关 线 程 池 的 使 用 技巧 


o http://it.deepinmind.com/java/2014/11/26/executorservice-10-tips- 
and-tricks.html 


e 有 关 Fork/Join 的 简单 实现 原理 
o http://www.infog.com/cn/articles/fork-join-introduction 


e 有 关 ConcurrentLinkedQueue 的 实现 具体 分 析 (其 使 用 的 JDK 版 本 
HAHA IA) 


o http://my.oschina.net/xianggao/blog/389332 


o http://www.ibm.com/developerworks/cn/java/j-lo-concurrent/ 








e 有 关 ConcurrentSkipListMap 的 运作 原理 (示例 图 示 很 好 ) 


o http://www.liuhaihua.cn/archives/40657.html 


第 4 草 ” 锁 的 优化 及 注意 事项 


“ 锁 ? 是 最 音 用 的 同步 方法 之 一 。 在 高 并 发 的 环境 下 ， 激 烈 的 锁 竞 争 
会 导致 程序 的 性 能 下 降 。 所 以 我 们 自然 有 必要 讨论 一 些 有 关 “ 锁 ”的 性 能 
问题 以 及 相关 一 些 注意 事项 。 比 如 : 避免 死 锁 、 减 小 锁 粒 度 、 锁 分 离 
A 
去 于 o 


在 多 核 时 代 ， 使 用 多 线程 可 以 明显 地 提高 系统 的 性 能 。 但 事实 上 ， 
使 用 多 线程 的 方式 会 额外 增加 系统 的 开销 。 


对 于 单 任务 或 者 单线 程 的 应 用 而 言 ， 其 主要 资源 消耗 都 伦 在 任务 本 
身 。 它 既 不 需要 维护 并 行 数 据 结 构 间 的 一 致 性 状态 ， 也 不 需要 为 线程 的 
切换 和 调度 花费 时 间 。 但 对 于 多 线程 应 用 来 说 ， 系 统 除 了 处 理 功能 需求 
外 ， 还 需要 额外 维护 多 线程 环境 的 特有 信息 ， 如 线程 本 里 的 元 数据 、 线 
程 的 调度 、 线 程 上 下 文 的 切换 等 。 











事实 上 ， 在 单 核 CPU 上 ， 采 用 并 行 算 法 的 效率 一 般 要 低 于 原始 的 串 
行 算法 的 ， 其 根本 原因 也 在 于 此 。 因 此 ， 并 行 计算 之 所 以 能 提高 系统 的 
性 能 ， 并 不 是 因为 它 “ 少 干 活 ” 了 ， 而 是 因为 并 行 计算 可 以 更 合理 地 进行 
任务 调度 ， 充 分 利用 各 个 CPU 资源 。 因 此 ， 合 理 的 并 发 ， 才 能 将 多 核 
CPU 的 性 能 发 挥 到 极致 。 





4.1 ADT iem re ae A Le 


AAA) 


i 


“ 锁 ” 的 苋 搜 必然 会 导致 程序 的 整体 性 能 下 降 。 为 了 将 这 种 副作用 降 
到 最 低 ， 我 这 里 提出 一 些 关 于 使 用 锁 的 建议 ， 和 希望 可 以 帮助 大 家 写 出 性 
能 更 为 优越 的 程序 。 


4.1.1 减 小 锁 持 有 时间 


对 于 使 用 锁 进行 并 肥 控 制 的 应 用 程序 而 言 ， 在 锁 范 争 过 程 中 ， 单 个 
线程 对 锁 的 持 有 时间 与 系统 性 能 有 着 直接 的 关系 。 如 果 线 程 持 有 锁 的 时 
间 很 长 ， 那 么 相对 地 ， 锁 的 苋 争 程度 也 就 越 油 烈 。 可 以 想象 一 下 ， 如 末 
要 求 100 个 人 各 目 填 写 目 己 的 身份 信息 ， 但 是 只 给 他 们 一 文笔 。 那 么 如 
果 每 个 人 拿 着 笔 的 时 间 都 很 长 ， 总 体 所 花 的 时 间 就 会 很 长 。 如 果真 的 只 
能 有 一 文笔 共 孚 给 100 个 人 用 ， 那 么 最 好 就 让 每 个 人 花 尽 量 少 的 时 间 持 
笔 ， 务 必 做 到 想 好 了 再 拿 笔 写 ， 千 万 不 可 拿 着 笔 才 去 思考 这 表格 应 该 怎 
么 填 。 程 序 开 发 也 是 类 似 的 ， 应 该 尽 可 能 地 减少 对 某 个 锁 的 占有 了 时间， 
以 减少 线程 间 互 斥 的 可 能 。 以 下 面 的 代码 段 为 例 : 











public synchronized void syncMethod(){ 
othercode1(); 
mutextMethod(); 


othercode2(); 





syncMethod() 方 法 中 ， 假 设 只 有 mnutextMethod() 方 法 是 有 同步 需要 
的 ， 而 othercode10 和 othercode20 并 不 需要 做 同步 控制 。 如 果 
othercode10 和 othercode20 分 别 是 重量 级 的 方法 ， 则 会 花费 较 长 的 CPU 时 
间 。 此 时 ， 如 果 在 并 发 量 较 大 ， 使 用 这 种 对 整个 方法 做 同步 的 方案 ， 会 
导致 等 待 线程 大 量 增 加 。 因 为 一 个 线程 ， 在 进入 该 方法 时 获得 内 部 锁 ， 
只 有 在 所 有 任务 都 执行 完 后 ， 才 会 释放 锁 。 








一 个 较为 优化 的 解决 方案 是 ， 只 在 必要 时 进行 同步 ， 这 样 就 能 明显 
减少 线程 持 有 锁 的 时 间 ， 提 高 系统 的 吞吐 量 。 


public void syncMethod2(){ 
othercode1(); 
synchronized(this) { 
mutextMethod(); 


} 
othercode2(); 


在 改进 的 代码 中 ， 只 针对 mutextMethod(0) 方 法 做 了 同步 ， 锁 占用 的 
时 间 相 对 较 短 ， 因 此 能 有 更 高 的 并 行 度 。 这 种 技术 手段 在 JDK 的 源码 包 
中 也 可 以 很 容易 地 找到 ， 比 如 处 理 正 则 表达 式 的 Pattern 类 : 





public Matcher matcher(CharSequence input) { 
if (!compiled) { 
synchronized(this) { 
if (!compiled) 


compile(); 


} 
Matcher m = new Matcher(this, input); 


return m; 


matcher() 方 法 有 条 件 地 进行 锁 申 请 ， 只 有 在 表达 式 未 编译 时 ， 进 行 
局 部 的 加 锁 。 这 种 处 理 方 式 大 大 提高 了 matcher() 方 法 的 执行 效率 和 可 靠 
性 。 





注意 : 减少 锁 的 持 有 时 间 有 助 于 降低 锁 冲 突 的 可 能 性 ， 进 而 提升 系 
统 的 并 发 能 


4.1.2 ” 减 小 锁 粒 度 


减 小 锁 粒 度 也 是 一 种 削弱 多 线程 锁 竞 争 的 有 效 手段 。 这 种 技术 典型 
的 使 用 场景 就 是 ConcurrentHashMap 类 的 实现 。 大 家 应 该 还 记得 这 个 类 
MEE TESS JDK 的 并 发 容器 ”一 节 中 ， 和 
HashMap。 但 ea a 它 的 实现 原理 。 这 里 ， 让 我 们 更 加 
细致 地 看 一 下 这 个 








对 于 HashMap 来 说 ， 最 重要 的 两 个 方法 就 是 get0 和 put(0。 一 种 最 自 
然 的 想法 就 是 对 整个 HashMap 加 锁 ， 必 然 可 以 得 到 一 个 线程 安全 的 对 
象 。 但 是 这 样 做 ， 我 们 就 认为 加 锁 粒度 太 大 。 对 于 
ConcurrentHashMap， 它 内 部 进一步 细 分 了 和 若干 个 小 的 HashMap， 称 之 
AEX (SEGMENT) 。 默 认 情 况 下 ， 一 个 ConcurrentHashMap 被 进一步 细 
分 为 16 个 段 。 





如 果 需 要 在 ConcurrentHashMap 中 增加 一 个 新 的 表 项 ， 并 不 是 将 整 
个 HashMap 加 锁 ， 而 是 首先 根据 hashcode 得 到 该 表 项 应 该 被 存放 到 哪个 
段 中 ， 然 后 对 该 段 加 锁 ， 并 完成 put0 操 作 。 在 多 线程 环境 中 ， 如 果 多 个 
线程 同时 进行 putO 操 作 ， 只 要 被 加 入 的 表 项 不 存放 在 同一 个 段 中 ， 则 线 
程 间 便 可 以 做 到 真正 的 并 行 。 





由 于 默认 有 16 个 段 ， 因 此 ， 如 果 人 够 幸运 的 话 ，ConcurrentHashMap 
可 以 同时 接受 16 个 线程 同时 插入 《如 宁都 插入 不 同 的 段 中 ) ， 从 而 大 大 
提供 其 吞吐 量 。 下 面 代码 显示 了 putO 操 作 的 过 程 。 在 第 5 一 6 行 ， 根 据 
key， 获 得 对 应 的 段 的 序号 。 接 着 在 第 9 行 ， 得 到 段 ， 然 后 将 数据 插入 给 
定 的 段 中 。 





01 public V put(K key, V value) { 


02 Segment<K,V> sS; 

03 if (value == null) 

04 throw new NullPointerException(); 

05 int hash = hash(key); 

06 int j = (hash >>> segmentShift) & segmentMask; 

07 if ((s = (Segment<K,V>)UNSAFE.getObject // 
08 (segments, (j << SSHIFT) + SBASE)) == null) // 
09 s = ensureSegment(j); 

10 return s.put(key, hash, value, false); 

11 } 








但 是 ， 减 少 锁 粒 度 会 引入 一 个 新 的 问题 ， 即 : 当 系 统 需 要 取得 全 局 
锁 时 ， 其 消耗 的 资源 会 比较 多 。 仍 然 以 ConcurrentHashMap 类 为 例 ， 虽 
然 其 put(0) 方 法 很 好 地 分 离 了 锁 ， 但 是 当 试 图 访问 ConcurrentHashMap 全 
局 信息 时 ， 就 会 需要 同时 取得 所 有 段 的 锁 方 能 顺利 实施 。 比 如 





ConcurrentHashMap 的 size() 方 法 ， 它 将 返回 ConcurrentHashMap 的 有 效 表 
项 的 数量 ， 即 ConcurrentHashMap 的 全 部 有 效 表 项 之 和 。 要 获取 这 个 信 
息 需 要 取得 所 有 子 段 的 锁 ， 因 此 ， 其 size0) 方 法 的 部 分 代码 如 下 : 





sum = 0; 

for (int i = 0; i < segments.length; ++i) // 对 所 有 | 
segments[i].lock(); 

for (int i = 0; i < segments.length; ++i) // 统 计 总 ; 
sum += segments[i].count; 

for (int i = 0; i < segments.length; ++i) // 释 放 所 ; 


segments[i].unlock(); 


可 以 看 到 在 计算 总 数 时 ， 先 要 获得 所 有 上 段 的 锁 ， 然 后 再 求 和 。 但 
是 ，ConcurrentHashMap 的 size() 方 法 并 不 总 是 这 样 执行 ， 事 实 上 ，size0) 
Re 如 果 失 败 才 会 尝试 这 种 加 锁 的 方法 。 但 
不 管 这 么 说 ， 在 高 并 发 场合 ConcurrentHashMap 的 size() 的 性 能 依然 要 差 
Benes 


-> 





因此 ， 只 有 在 类 似 于 size() 获 取 全 局 信息 的 方法 调用 并 不 频繁 时 ， 
这 种 减 小 锁 粒 度 的 方法 才能 真正 意义 上 提高 系统 吞吐 量 。 


oe 就 是 指 缩小 锁定 对 象 的 范围 ， 从 而 减少 锁 
提高 系统 的 并 发 能 


4.1.3” 读 写 分 离 锁 来 丛 换 独占 锁 


在 之 前 我 们 已 经 提 过 ， 使 用 读 写 锁 ReadWriteLock 可 以 提高 系统 的 


性 能 。 使 用 读 写 分 离 锁 来 珍 代 独占 锁 是 减 小 锁 粒 度 的 一 种 特殊 情况 。 如 
果 说 上 节 中 提 到 的 减少 锁 粒 度 是 通过 分 割 数据 结构 实现 的 ， 那 么 ， 读 写 
锁 则 是 对 系统 功能 点 的 分 割 。 


在 读 多 写 少 的 场合 ， 读 写 锁 对 系统 性 能 是 很 有 好 处 的 。 因 为 如 果 系 
统 在 读 写 数 据 时 均 只 使 用 独占 锁 ， 那 么 读 操 作 和 写 操作 间 、 读 操作 和 读 
操作 间 、 写 操作 和 写 操作 间 均 不 能 做 到 真正 的 并 发 ， 并 且 需 要 相互 等 
待 。 而 读 操作 本 身 不 会 影响 数据 的 完整 性 和 一 致 性 。 因 此 ， 理 论 上 讲 ， 
在 大 部 分 情况 下 ， 应 该 可 以 允许 多 线程 同时 读 ， 读 写 锁 正 是 实现 了 这 种 
功能 。 由 于 我 们 在 第 3 章 中 已 经 介绍 了 读 写 锁 ， 因 此 这 里 就 不 再 重复 
ce 











注意 : 在 读 多 写 少 的 场合 ， 使 用 读 写 锁 可 以 有 效 提 升 系统 的 并 发 能 
力 。 


41.4 is 


如 有 果 将 读 写 锁 的 思想 做 进一步 的 延伸 ， 就 是 锁 分 离 。 读 写 锁 根 据 读 
写 操作 功能 上 的 不 同 ， 进 行 了 有 效 的 锁 分 离 。 依 据 应 用 程序 的 功能 特 
点 ， 使 用 类 似 的 分 离 思想 ， 也 可 以 对 独占 锁 进 行 分 离 。 一 个 典型 的 案例 
就 是 java.util.concurrent.LinkedBlockingQueue 的 实现 (如 果 大 家 印象 深 
刻 ， 我 们 在 之 前 已 经 讨论 了 它 的 近亲 ArrayBlockingQueue 的 内 部 实 
现 ) 。 


在 LinkedBlockingQueue 的 实现 中 ，take0 函 数 和 put0 函 数 分 别 实现 
了 从 队列 中 取得 数据 和 往 队 列 中 增加 数据 的 功能 。 昌 然 两 个 函数 都 对 当 
前 队列 进行 了 修改 操作 ， 但 由 于 LinkedBlockingQueue 是 基于 链表 的 ， 


此 ， 两 个 操作 分 别 作 用 于 队列 的 前 并 和 尾 端 ， 从 理论 上 说 ， 两 者 并 不 冲 


A 

如 末 使 用 独占 锁 ， 则 要 求 在 两 个 操作 进行 时 获取 当前 队列 的 独占 
锁 ， 那 么 take0 和 putO 操 作 就 不 可 能 真正 的 并 发 ， 在 运行 时 ， 它 们 会 彼 
此 等 竺 对 方 释放 锁 资 源 。 在 这 种 情况 下 ， 锁 竞争 会 相对 比较 激烈 ， 从 而 
影 啊 程序 在 高 并 发 时 的 性 能 。 














因此 ， 在 JDK 的 实现 中 ， 并 没有 采用 这 样 的 方式 ， 取 而 代 之 的 是 两 
把 不 同 的 锁 ， 分 离 了 take0 和 put0O 操 作 。 


/** Lock held by take, poll, etc */ 

private final ReentrantLock takeLock = new ReentrantLock()j; // 
/** Wait queue for waiting takes */ 

private final Condition notEmpty = takeLock.newCondition(); 

/** Lock held by put, offer, etc */ 

private final ReentrantLock putLock = new ReentrantLock(); M 
/** Wait queue for waiting puts */ 


private final Condition notFull = putLock.newCondition(); 


以 上 代码 片段 ， 定 义 了 takeLock 和 putLock， 它 们 分 别 在 take0 操 作 
和 putO 操 作 中 使 用 。 因 此 ，take0 函 数 和 putO 函 数 就 此 相互 独立 ， 它 们 
之 间 不 存在 锁 竞 争 关系 ， 只 需要 在 take0 和 take0 间 、put0 和 putO 间 分 别 
对 takeLock 和 putLock 进 行 竞 争 。 从 而 ， 削 弱 了 锁 竞 争 的 可 能 性 。 





半 数 take() 的 实现 如 下 ， 笔 者 在 代码 中 给 出 了 详细 的 注释 ， 故 不 在 
正文 中 做 进一步 说 明 。 


public E take() throws InterruptedException { 


Eee 
int c = -1; 
final AtomicInteger count = this.count; 


final ReentrantLock takeLock = this.takeLock; 


takeLock.lockInterruptibly(); // 不 能 有 两 个 
try { 
try { 
while (count.get() == 0) // 如 果 当 前 没 
notEmpty.await(); // 等 待 ，put 


} catch (InterruptedException ie) { 








notEmpty.signal(); // 通 知 其 他 未 
throw ie; 
} 
x = extract(); // 取 得 第 一 个 
c = count.getAndDecrement(); // 数 量 减 1，| 
// 函 数 同时 访问 count。 注 意 : 变量 c 是 
//count 减 1 前 的 值 
if (c > 1) 
notEmpty.signal(); // 通 知 其 他 ti 
} finally { 
takeLock.unlock(); // 释 放 锁 
if (c == capacity) 
SignalNotFull(); // 通 知 put() 
return x; 


函数 putO 的 实现 如 下 ， 


public void put(E e) throws InterruptedException { 
if (e == null) throw new NullPointerException(); 
int c = -1; 
final ReentrantLock putLock = this.putLock; 


final AtomicInteger count = this.count; 


putLock.lockInterruptibly(); // 不 能 有 两 个 
try { 
try { 
while (count.get() == capacity) J JWR 2 
notFull.await(); // 等 待 


} catch (InterruptedException ie) { 





notFull.signal(); // 通 知 未 中 断 
throw ie; 

i 

insert(e); // 插 入 数据 

c = count.getAndIncrement(); // 更 新 总 数 ，2 


if (c + 1 < capacity) 





notFull.signal(); // EMG HZ Ii 
} finally { 
putLock.unlock(); // 释 放 锁 
上 
if (c == 0) 
signalNotEmpty(); // 插 入 成 功 后 ， 


通过 takeLock 和 putLock 两 把 锁 ，LinkedBlockingQueue 实 现 了 取 数 据 
和 写 数 据 的 分 离 ， 使 两 者 在 真正 意义 上 成 为 可 并 发 的 操作 。 


4.1.5” 锁 粗 化 


通常 情况 下 ， 为 了 保证 多 线程 间 的 有 效 并 发 ， 会 要 求 每 个 线程 持 有 
锁 的 时 间 尽 量 短 ， 即 在 使 用 完 公共 资源 后 ， 应 该 立即 释放 锁 。 只 有 这 
样 ， 等 竺 在 这 个 锁 上 的 其 他 线程 才能 尽早 地 获得 资源 执行 任务 。 但 是 ， 
凡事 都 有 一 个 度 ， 如 果 对 同一 个 锁 不 停 地 进行 请 求 、 同 步 和 释放 ， 其 本 
AAR SE ERA, Bom AAP ERE LL 


为 此 ， 虚 拟 机 在 遇 到 一 连 串 连续 地 对 同一 锁 不 断 进 行 请 求 和 释放 的 
操作 时 ， 便 会 把 所 有 的 锁 操 作 整 合成 对 锁 的 一 次 请 求 ， 从 而 减少 对 锁 的 
请 求 同 步 次 数 ， 这 个 操作 叫做 锁 的 粗 化 。 比 如 代码 段 : 


public void demoMethod(){ 
synchronized(lock) { 
//do sth. 
t 
// 做 其 他 不 需要 的 同步 的 工作 ， 但 能 很 快 执行 完毕 


synchronized(lock) { 








//do sth. 


Ww 


会 被 整合 成 如 下 形式 : 


public void demoMethod(){ 
// 整 合成 一 次 锁 请 求 
synchronized(lock)t{ 
//do sth. 
// 做 其 他 不 需要 的 同步 的 工作 ， 但 能 很 快 执行 完毕 














在 开发 过 程 中 ， 大 家 也 应 该 有 意识 地 在 合理 的 场合 进行 锁 的 粗 化 ， 
尤其 当 在 循环 内 请 求 锁 时 。 以 下 是 一 个 循环 内 请 求 锁 的 例子 ， 在 这 种 情 
况 下 ， 意 味 着 每 次 循环 都 有 申请 锁 和 释放 锁 的 操作 。 但 在 这 种 情况 下 ， 
显然 是 没有 必要 的 。 





for(int 1=0;i1<CIRCLE;i++){ 





synchronized(lock) { 

J 
t 

所 以 ， 一 种 更 加 合理 的 做 法 应 该 是 在 外 层 只 请 求 一 次 锁 ; 
synchronized(lock) { 


for(int 1=0;i<CIRCLE;i++){ 


注意 : 性 能 优化 就 是 根据 运行 时 的 真实 情况 对 各 个 资源 点 进行 权衡 


折 中 的 过 程 。 锁 粗 化 的 思想 和 减少 锁 持 有 时 间 是 相反 的 ， 但 在 不 同 
的 场合 ， 它 们 的 效果 并 不 相同 。 所 以 大 家 需要 根据 实际 情况 ， 进 行 
权衡 。 


4.2 Java 虚 拟 机 对 锁 优 化 所 做 的 努 
力 


作为 一 球 共 用 平台 ，JDK 本 喘 也 为 并 友 程 序 的 性 能 绞 尽 脑汁 。 在 
JDK 内 部 也 想 尽 一 切 办 法 提供 并 发 时 的 系统 吞吐 量 。 这 里 ， 我 将 辐 大 家 
简单 介绍 儿 种 JDK 内 部 的 “ 锁 ” 优 化 全 上 略 。 


4.2.1 锁 偏 向 


锁 偏 回 是 一 种 针对 加 锁 操 作 的 优化 手段 。 它 的 核心 思想 是 如果 一 
个 线程 获得 了 锁 ， 那 么 锁 束 进入 偶 癌 模式 。 当 这 个 线程 再 次 请 求 锁 时 ， 
无 须 再 做 任何 同步 操作 。 这 样 就 节省 了 大 量 有 关 锁 申请 的 操作 ， 从 而 提 
高 了 程序 性 能 。 因 此 ， 对 于 几乎 没有 锁 苋 争 的 场合 ， 偏 向 锁 有 比较 好 的 
优化 效果 ， 因 为 连续 多 次 极 有 可 能 是 同一 个 线程 请 求 相 同 的 锁 。 而 对 于 
锁 竞 争 比 较 激 烈 的 场合 ， 其 效果 不 佳 。 因 为 在 竞争 激烈 的 场合 ， 最 有 可 
能 的 情况 是 每 次 都 是 不 同 的 线程 来 请 求 相 同 的 锁 。 这 样 偏 癌 模式 会 失 
效 ， 因 此 还 不 如 不 启用 偏 回 锁 。 使 用 Java 虚 拟 机 参数 - 
XX:+UseBiasedLocking 可 以 开局 偏 问 锁 。 























4.2.2 ” 轻 量 级 锁 


如 果 偏 向 锁 失 败 ， 虚 拟 机 并 不 会 立即 挂 起 线程 。 它 还 会 使 用 一 种 称 
为 轻 量 级 锁 的 优化 手段 。 轻 量 级 锁 的 操作 也 很 轻便 ， 它 只 是 简单 地 将 对 


象 头 部 作为 指针 ， 指 向 持 有 锁 的 线程 堆栈 的 内 部 ， 来 判断 一 个 线程 是 否 
持 有 对 象 锁 。 如 果 线 程 获得 轻 量 级 锁 成 功 ， 则 可 以 顺利 进入 临界 区 。 如 
果 轻 量 级 锁 加 锁 失 败 ， 则 表示 其 他 线程 抢先 争夺 到 了 锁 ， 那 么 当前 线程 
的 锁 请 求 束 会 膨胀 为 重量 级 锁 。 


4.2.3 ”上 自 旋 锁 


锁 膨 胀 后 ， 虚 拟 机 为 了 避免 线程 真实 地 在 操作 系统 层面 挂 起 ， 虚 拟 
机 还 会 在 做 最 后 的 努力 一 一 自 旋 锁 。 由 于 当前 线程 暂时 无 法 获得 锁 ， 但 
征 什么 时 候 可 以 获得 锁 是 一 个 未 知 数 。 也 许 在 儿 个 CPU 时 钟 周期 后 ， 惑 
可 以 得 到 锁 。 如 果 这 样 ， 简 单 粗 暴 地 挂 起 线程 可 能 是 一 种 得 不 偿 失 的 操 
作 。 因 此 ， 系 统 会 进行 一 次 赌注 : 它 会 假设 在 不 久 的 将 来 ， 线 程 可 以 得 
到 这 把 锁 。 因 此 ， 虚 拟 机 会 让 当前 线程 做 几 个 空 循环 〈 这 也 是 目 旋 的 含 
义 ) ， 在 经 过 行 干 次 循环 后 ， 如 果 可 以 得 到 锁 ， 那 么 就 顺利 进入 临界 
区 。 如 果 还 不 能 获得 锁 ， 才 会 真实 地 将 线程 在 操作 系统 层面 挂 起 。 














4.2.4 锁 消 除 





锁 消 除 是 一 种 更 彻底 的 锁 优 化 。Java 虚 拟 机 在 JIT 编 译 时 ， 通 过 对 运 
行 上 下 文 的 扫描 ， 去 除 不 可 能 存在 共享 资源 竞争 的 锁 。 通 过 锁 消 除 ， 可 
以 节省 军 无 意义 的 请 求 锁 时 间 。 








说 到 这 里 ， 细 心 的 读者 可 能 会 产生 疑问 ， 如 果 不 可 能 存在 苋 争 ， 为 
什么 程序 员 还 要 加 上 锁 呢 ?这 是 因为 在 Java 软 件 开 发 过 程 中 ， 我 们 必然 
会 使 用 一 些 JDK 的 内 置 API， 比 如 StringBuffer、Vector 等 。 你 在 使 用 这 
些 类 的 时 候 ， 也 许 根 本 不 会 考虑 这 些 对 象 到 底 内 部 是 如 何 实 现 的 。 比 


如 ， 你 很 有 可 能 在 一 个 不 可 能 存在 并 发 竞争 的 场合 使 用 Vector。 而 众 所 
周知 ，Vector 内 部 使 用 了 synchronized 请 求 锁 。 比 如 下 面 的 代码 : 


public String[] createStrings(){ 
Vector<String> v=new Vector<String>(); 
for(int 1=0;1<100;i++){ 
v.add(Integer.toString(1)); 
i 
return v.toArray(new String[]{}); 





注意 上 述 代码 中 的 Vector， 由 于 变量 v 只 在 createStringsO 函 数 中 使 
用 ， 因 此 ， 它 只 是 一 个 单纯 的 局 部 变量 。 局 部 变量 是 在 线程 栈 上 分 配 
的 ， 属 于 线程 私有 的 数据 ， 因 此 不 可 能 被 其 他 线程 访问 。 所 以 ， 在 这 种 
情况 下 ，Vector 内 部 所 有 加 锁 同步 都 是 没有 必要 的 。 如 果 虚 拟 机 检测 到 
这 种 情况 ， 就 会 将 这 些 无 用 的 锁 操 作 去 除 。 











锁 消 除 涉 及 的 一 项 关键 技术 为 逃逸 分 析 。 所 谓 逃 逸 分 析 束 是 观察 某 
一 个 变量 是 否 会 逃 出 某 一 个 作用 域 。 在 本 例 中 ， 变 量 v 显 然 没 有 逃 出 
createStrings0 函 数 之 外 。 以 次 为 基础 ， 虚 拟 机 才 可 以 大 胆 地 将 v 内 部 的 
加 锁 操 作 去 除 。 如 果 createStrings() 返 回 的 不 是 String 数 组 ， 而 是 Vv 本 里， 
那么 束 认 为 变量 逃逸 出 了 当前 函数 ， 也 就 是 说 v 有 可 能 被 其 他 线程 访 
问 。 如 果 是 这 样 ， 虚 拟 机 就 不 能 消除 v 中 的 锁 操作 。 





逃逸 分 析 必 须 在 -server 模 式 下 进行 ， 可 以 使 用 - 
XX:+DoEscapeAnalysis 参 数 打开 逃逸 分 析 。 使 用 -XX:+FEliminateLocks 参 
数 可 以 打开 锁 消 除 。 


43 ” 人手 一 文笔 : ThreadLocal 


除了 控制 资源 的 访问 外 ， 我 们 还 可 以 通过 增加 资源 来 保证 所 有 对 象 
的 线程 安全 。 比 如 ， 让 100 个 人 填写 个 人 信息 表 ， 如 果 只 有 一 文笔 ， 那 
么 大 家 就 得 换个 填写 ， 对 于 管理 人 员 来 次， 必须 保证 大 家 不 会 去 哄抢 这 
仅 存 的 一 文笔 ， 否 则 ， 谁 也 填 不 完 。 从 另外 一 个 角度 出 发 ， 我 们 可 以 干 
脆 就 准备 100 文 笔 ， 人 手 一 文 ， 那 么 所 有 人 都 可 以 各 目 为 营 ， 很 快 就 能 
完成 表格 的 填写 工作 。 





如 果 说 锁 是 使 用 第 一 种 思路 ， 那 么 ThreadLocal 就 是 使 用 第 二 种 思路 
ce 


4.3.1 ThreadLocal 的 人 简单 使 用 





从 ThreadLocal 的 名 字 上 可 以 看 到 ， 这 是 一 个 线程 的 局 部 变量 。 也 就 
是 说 ， 只 有 当前 线程 可 以 访问 。 既 然 是 只 有 妆 前 线程 可 以 访问 的 数据 ， 
目 然 是 线程 安全 的 。 


下 面 来 看 一 个 简单 的 示例 : 


01 private static final SimpleDateFormat sdf = new SimpleDateFor 
02 public static class ParseDate implements Runnable{ 

03 int i=0; 

04 public ParseDate(int i){this.i=1;} 


05 public void run() { 


06 try { 


07 Date t=sdf.parse("2015-03-29 19:29:"+i%60); 
08 System.out.println(i+":"+t); 

09 } catch (ParseException e) { 

10 e.printStackTrace(); 

11 } 

12 } 

1g Y} 


14 public static void main(String[] args) { 


15 ExecutorService es=Executors.newFixedThreadPool(10); 
16 for(int i=0;i<1000;i++){ 

17 es.execute(new ParseDate(i)); 

18 } 

19 } 


上 述 代 码 在 多 线程 中 使 用 SimpleDateFormat 来 解析 字符 串 类 型 的 日 
期 。 如 果 你 执行 上 述 代码 ， 一 般 来 说 ， 你 很 可 能 得 到 一 些 异 常 〈 篇 幅 有 
限 不 再 给 出 堆栈 ， 只 给 出 异常 名 称 ) : 


Exception in thread "pool-1-thread-26" java.lang.NumberFormatExce 


Exception in thread "pool-1-thread-17" java.lang.NumberFormatExce 


出 现 这 些 问题 的 原因 ， 是 SimipleDateFormat.parse() 方 法 并 不 是 线程 
安全 的 。 因 此 ， 在 线程 池 中 共享 这 个 对 象 必然 导致 错误 。 





一 种 可 行 的 方案 是 在 sdf.parseO) 前 后 加 锁 ， 这 也 是 我 们 一 般 的 处 理 
思路 。 这 里 我 们 不 这 么 做 ， 我 们 使 用 ThreadLocal 为 每 一 个 线程 都 产生 一 
个 SimpleDateformat 对 象 实例 : 


01 static ThreadLocal<SimpleDateFormat> tl=new ThreadLocal<Simp 


02 public static class ParseDate implements Runnable{ 


03 int i=0; 

04 public ParseDate(int i){this.i=1i;} 

05 public void run() { 

06 try { 

07 if(tl.get()==null){ 

08 tl.set(new SimpleDateFormat ("yyyy-MM-dd HH:mm: 
09 } 

10 Date t=tl.get().parse("2015-03-29 19:29:"+1i%60); 
11 System.out.printlin(it":"+t); 

12 } catch (ParseException e) { 

13 e.printStackTrace(); 

14 } 

15 } 

16 } 


上 述 代码 第 7 一 9 行 ， 如 果 当 前 线程 不 持 有 SimpleDateformat 对 象 实 
例 。 那 么 就 新 建 一 个 并 把 它 设置 到 当前 线程 中 ， 如 果 已 经 持 有 ， 则 直接 
使 用 。 


从 这 里 也 可 以 看 到 ， 为 每 一 个 线程 人 手 分 配 一 个 对 象 的 工作 并 不 是 
由 ThreadLocal 来 完成 的 ， 而 是 需要 在 应 用 层面 保证 的 。 如 果 在 应 用 上 为 
每 一 个 线程 分 配 了 相同 的 对 象 实例 ， 那 么 ThreadLocal 也 不 能 保证 线程 安 
全 。 这 点 也 需要 大 家 注意 。 





注意 : 为 每 一 个 线程 分 配 不 同 的 对 象 ， 需 要 在 应 用 层面 保证 。 
ThreadLocal 只 是 起 到 了 简单 的 容器 作用 。 


4.3.2 ThreadLocal 的 实现 原理 


那 ThreadLocal 叉 是 如 何 保证 这 些 对 象 只 被 当前 线程 所 访问 呢 ? 下面 
让 我 们 一 起 深入 ThreadLocal 的 内 部 实现 。 


我 们 需要 关注 的 ， 自 然 是 ThreadLocal 的 set() 方 法 和 get(O) 方 法 。 从 
set() 方 法 先 说 起 : 


public void set(T value) { 
Thread t = Thread.currentThread(); 
ThreadLocalMap map = getMap(t); 
if (map != null) 
map.set(this, value); 
else 


createMap(t, value); 





在 set 时 ， 首 先 获得 当前 线程 对 象 ， 然 后 通过 getMap0) 拿 到 线程 的 
ThreadLocalMap， 并 将 值 设 入 ThreadLocalMap 中 。 而 ThreadLocalMap 可 
以 理解 为 一 个 Map 《虽然 不 是 ， 但 是 你 可 以 把 它 简单 地 理解 成 
HashMap) ， 但 是 它 是 定义 在 Thread 内 部 的 成 员 。 注 意 下 面 的 定义 是 从 
Thread 类 中 摘出 来 的 : 





ThreadLocal.ThreadLocalMap threadLocals = null; 


而 设置 到 ThreadLocal 中 的 数据 ， 也 正 是 写 入 了 threadLocals 这 个 
Map。 其 中 ，key 为 ThreadLocal 当 前 对 象 ，value 就 是 我 们 需要 的 值 。 而 
threadLocals 本 里 束 保 存 了 当前 自己 所 在 线程 的 所 有 “局 部 变量 *?"， 也 就 是 





一 个 ThreadLocal 变 量 的 集合 。 





在 进行 getO 操 作 时 ， 上 自然 就 是 将 这 个 Map 中 的 数据 拿 出 来 : 


public T get() { 
Thread t = Thread.currentThread()j; 
ThreadLocalMap map = getMap(t); 
if (map != null) { 
ThreadLocalMap.Entry e = map.getEntry(this); 
if (e != null) 
return (T)e.value; 


} 


return setInitialValue(); 





首先 ，get(0) 方 法 也 是 先 取 得 当前 线程 的 ThreadLocalMap 对 象 。 然 
后 ， 通 过 将 自己 作为 key 取 得 内 部 的 实际 数据 。 





在 了 解 了 ThreadLocal 的 内 部 实现 后 ， 我 们 自然 会 引出 一 个 问题 。 那 
eee Te A S Tiea dE peal Map Ait 
这 也 意味 着 只 要 线程 不 退出 ， 对 象 的 引用 将 一 直 存 在 。 








当 线 程 退 出 时 ，Thread 类 会 进行 一 些 清理 工作 ， 其 中 就 包括 清理 
ThreadLocalMap， 注 意 下 述 代码 的 加 粗 部 分 : 














/** 
* 在 线程 退出 前 ， 由 系统 回调 ， 进 行 资源 清理 


private void exit() { 


if (group != null) { 
group.threadTerminated(this); 
group = null; 

} 

target = null; 

/* 加 速 资 源 清理 */ 





threadLocals = null; 
inheritableThreadLocals = null; 
inheritedAccessControlContext = null; 
blocker = null; 
uncaughtExceptionHandler = null; 


} 





因此 ， 如 果 我 们 使 用 线程 池 ， 那 就 意味 着 当前 线程 未 必 会 退出 ( 比 
如 固定 大 小 的 线程 池 ， 线 程 总 是 存在 ) 。 如 果 这 样 ， 将 一 些 大 大 的 对 象 
设置 到 ThreadLocal 中 〈( 它 实际 保存 在 线程 持 有 的 threadLocals Map 
内 ) ， 可 能 会 使 系统 出 现 内 存 泄露 的 可 能 (这 里 我 的 意思 是 : 你 设置 了 
对 象 到 ThreadLocal 中 ， 但 是 不 清理 它 ， 在 你 使 用 几 次 后 ， 这 个 对 象 也 不 
再 有 用 了 ， 但 是 它 却 无 法 被 回收 ) 。 





此 时 ， 如 果 你 希望 及 时 回收 对 象 ， 最 好 使 用 ThreadLocal.remove() 方 
法 将 这 个 变量 移 除 。 束 像 我 们 习惯 性 地 关闭 数据 库 连接 一 样 。 如 果 你 确 
实 不 需要 这 个 对 象 了 ， 那 么 就 应 该 告诉 虚拟 机 ， 请 把 它 回 收 掉 ， 防 止 内 
AFTER o 





另外 一 种 有 趣 的 情况 是 JDK 也 可 能 允许 你 像 释放 普通 变量 一 样 释放 
ThreadLocal。 比 如 ， 我 们 有 时 候 为 了 加 速 志 圾 回收 ， 会 特意 写 出 类 似 
obj=null 之 类 的 代码 。 如 果 这 么 做 ，obj 所 指向 的 对 象 就 会 更 容易 地 被 垃 


圾 回收 顷 发 现 ， 从 而 加 速 回 收 。 


同 理 ， 如 果 对 于 ThreadLocal 的 变量 ， 我 们 也 手动 将 其 设置 为 null， 
比如 t=null。 那 么 这 个 ThreadLocal 对 应 的 所 有 线程 的 局 部 变量 都 有 可 能 
被 回收 。 这 里 面 的 奥秘 是 什么 呢 ? 先 来 看 一 个 简单 的 例子 : 





01 public class ThreadLocalDemo_Gc { 


02 static volatile ThreadLocal<SimpleDateFormat> tl = new Threa 


03 protected void finalize() throws Throwable { 

04 System.out.printin(this.toString() + " is gc"); 

05 } 

06 ie 

07 static volatile CountDownLatch cd = new CountDownLatch(100 
08 public static class ParseDate implements Runnable { 

09 int i = 0; 

10 public ParseDate(int i) { 

qil this.i = 1; 

12 } 

13 public void run() { 

14 try { 

15 if (tl.get() == null) { 

16 tl.set(new SimpleDateFormat("yyyy-MM-dd HH 
17 protected void finalize() throws Throw 
18 System.out.printin(this.toString() 
19 } 

20 t); 


21 System.out.printin(Thread.currentThread().getId() 


22 
23 
24 
25 
26 
27 
28 
29 
30 
31 
32 
33 
34 
35 
36 
37 
38 
39 
40 
41 
42 
43 
44 
45 
46 
47 
48 


} 
Date t = tl.get().parse("2015-03-29 19:29:" + 


} catch (ParseException e) { 
e.printStackTrace(); 
} finally { 


cd.countDown(); 


public static void main(String[] args) throws InterruptedE 
ExecutorService es = Executors.newFixedThreadPool(10); 
for (int i = 0; i < 10000; i++) { 
es.execute(new ParseDate(i)); 
} 
cd.await(); 
System.out.println("mission complete!!"); 
tl = null; 
System.gc(); 
System.out.printin("first GC complete!!"); 
// 在 设置 ThreadLocal 的 时 候 ， 会 清除 ThreadLocalMap 中 的 无 效 对 象 
tl = new ThreadLocal<SimpleDateFormat>()j; 
cd = new CountDownLatch(10000) ; 
for (int i = 0; 1 < 10000; it+) { 
es.execute(new ParseDate(i)); 


J 


cd.await(); 


49 Thread.sleep(1000); 


50 System.gc(); 

51 System.out.printin("second GC complete!!"); 
52 } 

Se 


上 述 案 例 是 为 了 跟踪 ThreadLocal 对 象 以 及 内 部 SimpleDateFormat 对 
象 的 垃圾 回收 。 为 此 ， 我 们 在 第 3 行 和 第 17 行 ， 重 载 了 finalize0) 方 法 。 这 
样 ， 我 们 在 对 象 被 回收 时 ， 束 可 以 看 到 它们 的 踊 迹 。 


在 主 函数 main 中 ， 先 后 进行 了 两 次 任务 提交 ， 每 次 10000 个 任务 。 
在 第 一 次 任务 提交 后 ， 代 码 第 39 行 ， 我 们 将 t 设 置 为 null， 接 着 进行 一 次 
GC。 接 着 ， 我 们 进行 第 2 次 任务 提交 ， 完 成 后 ， 在 第 50 行 再 进行 一 次 
GC. 





如 宁 你 执行 上 述 代 码 ， 则 最 有 可 能 的 一 种 输出 如 下 : 


10:create SimpleDateFormat 
11:create SimpleDateFormat 
13:create SimpleDateFormat 
17:create SimpleDateFormat 
14:create SimpleDateFormat 
8:create SimpleDateFormat 
16:create SimpleDateFormat 
15:create SimpleDateFormat 
12:create SimpleDateFormat 
9:create SimpleDateFormat 


mission complete! ! 


first GC complete! ! 
geym.conc.ch4.tl.ThreadLocalDemo_Gc$1@15f157b is gc 

9:create SimpleDateFormat 

8:create SimpleDateFormat 

16:create SimpleDateFormat 

13:create SimpleDateFormat 

15:create SimpleDateFormat 

10:create SimpleDateFormat 

11:create SimpleDateFormat 

14:create SimpleDateFormat 

17:create SimpleDateFormat 

12:create SimpleDateFormat 

second GC complete! ! 
geym.conc.ch4.tl.ThreadLocalDemo_Gc$ParseDate$1@4f76fia0 is gc 
geym.conc.ch4.tl.ThreadLocalDemo_Gc$ParseDate$1@4f76fia0 is gc 
geym.conc.ch4.tl.ThreadLocalDemo_Gc$ParseDate$1@4f76fia0 is gc 
geym.conc.ch4.tl.ThreadLocalDemo_Gc$ParseDate$1@4f76fia0 is gc 
geym.conc.ch4.tl.ThreadLocalDemo_Gc$ParseDate$1@4f76fia0 is gc 
geym.conc.ch4.tl.ThreadLocalDemo_Gc$ParseDate$1@4f76fia0 is gc 
geym.conc.ch4.tl.ThreadLocalDemo_Gc$ParseDate$1@4f76fia0 is gc 
geym.conc.ch4.tl.ThreadLocalDemo_Gc$ParseDate$1@4f76fia0 is gc 
geym.conc.ch4.tl.ThreadLocalDemo_Gc$ParseDate$1@4f76fia0 is gc 


geym.conc.ch4.tl.ThreadLocalDemo_Gc$ParseDate$1@4f76fia0 is gc 


注意 这 些 输出 所 代表 的 含义 。 首 先 ， 线 程 池 中 10 个 线程 都 各 上 自 创建 
了 一 个 SimpleDateFormat 对 象 实 例 。 接 着 进行 第 一 次 GC， 可 以 看 到 
ThreadLocal 对 象 被 回收 了 (这 里 使 用 了 匿名 类 ， 所 以 类 名 看 起 来 有 点 


怪 ， 这 个 类 束 是 第 2 行 创建 的 对 象 )。 接 着 提交 了 第 2 次 任务 ， 这 次 一 
样 也 创建 了 10 个 SimpleDateFormat 对 象 。 然 后 ， 进 行 第 2 次 GC。 可 以 看 
到 ， 在 第 2 次 GC 后 ， 第 一 次 创建 的 10 个 SimpleDateFormat 子 类 实例 全 部 
被 回收 。 可 以 看 到 ， 虽 然 我 们 没有 手工 ramove0O 这 些 对 象 ， 但 是 系统 依 
然 有 可 能 回收 它们 (注意 ， 这 段 代 码 是 在 JDK 7 中 输出 的 ， 在 JDK 8 中 ， 
你 也 许 得 不 到 类 似 的 输出 ， 大 家 可 以 比较 两 个 JDK 版 本 之 间 线 程 持 有 

ThreadLocal 变 量 的 不 同 ) 。 


要 了 解 这 里 的 回收 机 制 ， 我 们 需要 更 进一步 了 解 
Thread.ThreadLocalMap 的 实现 。 之 前 我 们 说 过 ，ThreadLocalMap 是 一 个 
类 似 HashMap 的 东西 。 更 精确 地 说 ， 它 更 加 类 似 WeakHashMap。 


ThreadLocalMap 的 实现 使 用 了 弱 引 用 。 弱 引用 是 比 强 引用 弱 得 多 的 
引用 。Java 虚 拟 机 在 垃圾 回收 时 ， 如 果 发 现 弱 引 用 ， 就 会 立即 回收 。 
ThreadLocalMap 内 部 由 一 系列 Entry 构 成 ， 每 一 个 Entry 都 是 
WeakReference< ThreadLocal> : 


static class Entry extends WeakReference<ThreadLocal> { 
/** The value associated with this ThreadLocal. */ 
Object value; 
Entry(ThreadLocal k, Object v) { 
super(k); 


value = v; 


这 里 的 参数 k 束 是 Map 的 key，v 束 是 Map 的 value。 其 中 Kk 也 就 是 
ThreadLocal 实 例 ， 作 为 弱 引 用 使 用 (super(k) 束 是 调用 了 WeakReference 


的 构造 函数 ) 。 因 此 ， 虽 然 这 里 使 用 ThreadLocal 作 为 Map 的 key， 但 是 
实际 上 ， 它 并 不 真 的 持 有 ThreadLocal 的 引用 。 而 当 ThreadLocal 的 外 部 

强 引 用 被 回收 时 ，ThreadLocalMap 中 的 key 束 会 变 成 hull。 当 系统 进行 

ThreadLocalMap 清 理 时 (比如 将 新 的 变量 加 入 表 中 ， 束 会 自动 进行 一 次 
清理 ， 虽 然 JDK 不 一 定 会 进行 一 次 彻底 的 扫描 ， 但 显然 在 我 们 这 个 案例 
中 ， 它 奏效 了 ) ， 就 会 自然 将 这 些 垃圾 数据 回收 。 整 个 结构 如 图 4.1 所 
示 。 
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图 4.1 ThreadLocal 的 回收 机 制 


4.3.3 ”对 性 能 有 何 帮 助 


为 每 一 个 线程 分 配 一 个 独立 的 对 象 对 系统 性 能 也 许 是 有 帮助 的 。 妆 
然 了 ， 这 也 不 一 定 ， 这 完全 取决 于 共享 对 象 的 内 部 逻辑 。 如 果 共 享 对 象 
对 于 竞争 的 处 理 容 易 引 起 性 能 损失 ， 我 们 还 是 应 该 考虑 使 用 ThreadLocal 
为 每 个 线程 分 配 单独 的 对 象 。 一 个 典型 的 案例 就 是 在 多 线程 下 产生 随机 
数 。 








这 里 ， 让 我 们 简单 测试 一 下 在 多 线程 下 产生 随机 数 的 性 能 问题 。 首 


先 ， 我 们 定义 一 些 全 局 变量 : 


01 public static final int GEN_COUNT = 10000000; 
02 public static final int THREAD_COUNT = 4; 


03 static ExecutorService exe = Executors.newFixedThreadPool (THRE 


04 public static Random rnd = new Random(123); 


05 


06 public static ThreadLocal<Random> tRnd = new ThreadLocal<Ran 


07 @Override 

08 protected Random initialValue() { 
09 return new Random(123); 

10 } 

a bale ee 


代码 第 1 行 定义 了 每 个 线程 要 产生 的 随机 数 数 量 ， 第 2 行 定义 了 参与 


工作 的 线程 数量 ， 第 3 行 定 义 了 线程 池 ， 第 4 行 定 义 了 被 多 线程 共享 的 
Random 实 例 用 于 产生 随机 数 ， 第 6 一 11 行 定义 了 由 ThreadLocal 封 装 的 


Random. 


接着 ， 定 义 一 个 工作 线程 的 内 部 逻辑 。 它 可 以 工作 在 两 种 模式 下 : 





第 一 是 多 线程 共享 一 个 Random (mode=0) , 
第 二 是 多 个 线程 各 分 配 一 个 Random (mode=1) 。 


01 public static class RndTask implements Callable<Long> { 
02 private int mode = 0; 


03 


public RndTask(int mode) { 


this.mode = mode; 


public Random getRandom() { 
if (mode == 0) { 
return rnd; 
} else if (mode == 1) { 
return tRnd.get(); 
} else { 


return null; 


@Override 
public Long call() { 
long b = System.currentTimeMillis(); 
for (long i = 0; i < GEN_COUNT; i++) { 
getRandom().nextInt(); 
} 
long e = System.currentTimeMillis(); 
System.out.printin(Thread.currentThread().getName() + 


return e - b; 


述 代码 第 19 一 27 行 定义 了 线程 的 工作 内 容 。 每 个 线程 会 产生 知 干 


个 随机 数 ， 完 成 工作 后 ， 记 录 并 返回 所 消耗 的 时 间 。 


最 后 是 我 们 的 main() 函 数 ， 它 分 别 对 上 述 两 种 情况 进行 测试 ， 并 打 
印 了 测试 的 耗 时 : 


01 public static void main(String[] args) throws InterruptedExcep 





02 Future<Long>[] futs = new Future[THREAD COUNT]; 

03 for (int 1 = 0; i < THREAD_COUNT; i++) { 

04 futs[i] = exe.submit(new RndTask(0)); 

05 } 

06 long totaltime = 0; 

07 for (int 1 = 0; i < THREAD_COUNT; i++) { 

08 totaltime += futs[i].get(); 

09 } 

10 System,out.printlLn(" 多 线程 访问 同一 个 Random 实 例 :" + totaltime - 
11 

12 //ThreadLocal 的 情况 

13 for (int 1 = 0; i < THREAD_COUNT; i++) { 

14 futs[i] = exe.submit(new RndTask(1)); 

15 } 

16 totaltime = 0; 

17 for (int 1 = 0; i < THREAD_COUNT; i++) { 

18 totaltime += futs[i].get(); 

19 } 

20 System.out ,println(" 使 用 ThreadLocal 包 装 Random 实 例 :" + totalt 
21 exe.shutdown(); 


22% 


上 述 代 码 的 运行 结果 ， 可 能 如 下 : 


pool-1-thread-3 spend 3398ms 
pool-1-thread-1 spend 3436ms 
pool-1-thread-2 spend 3495ms 
pool-1-thread-4 spend 3513ms 

多 线程 访问 同一 个 Random 实 例 :13842ms 
pool-1-thread-4 spend 375ms 
pool-1-thread-1 spend 429ms 
pool-1-thread-2 spend 453ms 
pool-1-thread-3 spend 499ms 

使 用 ThreadLocal 包 装 Random 实 例 :1756ms 





很 明显 ， 在 多 线程 共享 一 个 Random 实 例 的 情况 下 ， 总 耗 时 达 13 秒 
之 多 (这 里 是 指 4 个 线程 的 耗 时 总 和 ， 不 是 程序 执行 的 经 历时 间 ) 。 而 
在 ThreadLocal 模 式 下 ， 仪 耗 时 1.7 秒 左右 。 
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束 人 的 性 格 而 言 ， 我 们 可 以 分 为 乐天 派 和 莫 观 派 。 对 于 乐天 派 来 
说 ， 总 是 会 把 事情 往 好 的 方面 想 。 他 们 认为 所 有 事情 总 是 不 太 容 易 发 生 
问题 ， 出 错 是 小 概率 的 ， 所 以 我 们 可 以 肆 无 忌 昼 地 做 事 。 如 果真 的 不 入 
遇 到 了 问题 ， 则 有 则 改 之 无 则 加 勉 。 而 对 于 悲观 的 人 群 来 说 ， 他 们 总 是 
担 惊 受 但 ， 认 为 出 错 是 一 种 利 态 ， 所 以 无 论 巨 细 ， 都 考虑 得 面面俱到 ， 
滴水 不 漏 ， 确 保 为 人 处 世 ， 万 无 一 失 。 











对 于 并 发 控制 而 言 ， 锁 是 一 种 悲观 的 策略 。 它 总 是 假设 每 一 次 的 临 
界 区 操作 会 产生 种 突 ， 因 此 ， 必 须 对 每 次 操作 都 小 心 囊 辟 。 如 果 有 多 个 
线程 同时 需要 访问 临界 区 资源 ， 就 宁可 牺牲 性 能 让 线程 进行 等 待 ， 所 以 
说 锁 会 阻塞 线程 执行 。 而 无 锁 是 一 种 乐观 的 策略 ， 它 会 假设 对 资源 的 访 
问 是 没有 冲突 的 。 既 然 没 有 冲突 ， 自 然 不 需要 每 待 ， 所 以 所 有 的 线程 都 
可 以 在 不 停顿 的 状态 下 持续 执行 。 那 遇 到 冲突 怎么 办 呢 ? 无 锁 的 策略 使 
用 一 种 叫做 比较 交换 的 技术 (CAS Compare And Swap) 来 鉴别 线程 冲 
R, 一旦 检测 到 冲突 产生 ， 束 重 试 当前 操作 直到 没有 冲突 为 止 。 


4.4.1 与 众 不 同 的 并 及 策略 : 比较 区 
if (CAS) 











与 锁 相 比 ， 使 用 比较 交换 《下 文 简称 CAS) 会 使 程序 看 起 来 更 加 复 
杂 一 些 。 但 由 于 其 非 阻 暑 性 ， 它 对 死 锁 问 题 天 生 免 疫 ， 并 且 ， 线 程 间 的 
相互 影响 也 远 远 比 基 于 锁 的 方式 要 小 。 更 为 重要 的 是 ， 使 用 无 锁 的 方式 








完全 没有 锁 苑 争 带 来 的 系统 开销 ， 也 没有 线程 间 频 繁 调度 和 市 来 的 开销 ， 
因此 ， 它 要 比 基 于 锁 的 方式 拥有 更 优越 的 性 能 。 


CAS 算 法 的 过 程 是 这 样 : 它 包 含 三 个 参数 CAS(V,E,N)。V 表 示 要 更 
新 的 变量 ，E 表 示 预 期 值 ，N 表 示 新 值 。 仅 当 V 值 等 于 E 值 时 ， 才 会 将 V 
的 值 设 为 N， 如 果 V 值 和 E 值 不 同 ， 则 说 明 已 经 有 其 他 线程 做 了 更 新 ， 则 
当前 线程 什么 都 不 做 。 最 后 ，CAS 返 回 当前 V 的 真实 值 。CAS 操 作 是 抱 
独 乐 观 的 态度 进行 的 ， 它 总 是 认为 目 己 可 以 成 功 完成 操作 。 当 多 个 线程 
同时 使 用 CAS 操 作 一 个 变量 时 ， 只 有 一 个 会 胜出 ， 并 成 功 更 新 ， 其 余 均 
会 失败 。 失 败 的 线程 不 会 被 挂 起 ， 仅 是 被 告知 失败 ， 并 且 多 许 再 次 和 洽 
试 ， 当 然 也 允许 失败 的 线程 放 径 操作 。 基 于 这 样 的 原理 ，CAS 操 作 即 使 
没有 锁 ， 也 可 以 发 现 其 他 线程 对 当前 线程 的 和 干扰， 并 进行 恰当 的 处 理 。 





简单 地 说 ，CAS 需 要 你 额外 给 出 一 个 期 望 值 ， 也 就 是 你 认为 这 个 变 
量 现 在 应 该 是 什么 样子 的 。 如 果 变 量 不 是 你 想象 的 那样 ， 那 说 明 它 已 经 
被 别人 修改 过 了 。 你 就 重新 读 取 ， 再 次 尝试 修改 就 好 了 。 








在 硬件 层面 ， 大 部 分 的 现代 处 理 需 都 已 经 文 持 原子 化 的 CAS 指 令 。 
在 JDK ”5.0 以后， 虚拟 机 便 可 以 使 用 这 个 指令 来 实现 并 发 操作 和 并 发 数 
据 结 构 ， 并 且 ， 这 种 操作 在 虚拟 机 中 可 以 说 是 无 处 不 在 。 


4.4.2 ”无 锁 的 线程 安全 整数 : 
AtomicInteger 


为 了 让 Java 程 序 员 能 够 受益 于 CAS 等 CPU 指令 ，JDK 并 发 包 中 有 一 
个 atomic 包 ， 里 面 实现 了 一 些 直接 使 用 CAS 操 作 的 线程 安全 的 类 型 。 


其 中 ， 最 常用 的 一 个 类 ， 应 该 就是 AtomicInteger。 你 可 以 把 它 看 做 
是 一 个 整数 。 但 是 与 Integer 不 同 ， 它 是 可 变 的 ， 并 且 是 线程 安全 的 。 对 





其 进行 修改 等 任何 操作 ， 都 是 用 CAS 指 令 进 行 的 。 这 里 简单 列举 一 下 
AtomicInteger 的 一 些 主要 方法 ， 对 于 其 他 原子 类 ， 操 作 也 是 非常 类 似 


的 : 

public final int get() // 取 得 当前 值 
public final void set(int newValue) // 设 置 当前 值 
public final int getAndSet(int newValue) // 设 置 新 值 ， 


public final boolean compareAndSet(int expect, int u) // 如 果 当 前 值 








public final int getAndIncrement() // 当 前 值 加 1 
public final int getAndDecrement() // 当 前 值 减 1， 
public final int getAndAdd(int delta) // 当 前 值 增加 
public final int incrementAndGet() // 当 前 值 加 1， 
public final int decrementAndGet() // 当 前 值 减 1， 
public final int addAndGet(int delta) // 当 前 值 增加 


就 内 部 实现 上 来 说 ，AtomicInteger 中 保存 一 个 核心 字段 : 


private volatile int value; 


它 就 代表 了 AtomicInteger 的 当前 实际 取 值 。 此 外 还 有 一 个 : 


private static final long valueOffset; 








它 保 存 着 value 字 段 在 AtomicInteger 对 象 中 的 偏 移 量 。 后 面 你 会 看 


到 ， 这 个 偏 移 量 是 实现 AtomicInteger 的 关键 。 


AtomicInteger 的 使 用 非常 简单 ， 这 里 给 出 一 个 示例 : 


01 public class AtomicIntegerDemo { 


02 static AtomicInteger i=new AtomicInteger(); 

03 public static class AddThread implements Runnable{ 
04 public void run(){ 

05 for(int k=0;k<10000; k++) 

06 1.incrementAndGet(); 

07 } 

08 } 

09 public static void main(String[] args) throws InterruptedE 
10 Thread[] ts=new Thread[10]; 

11 for(int k=0;k<10;k++){ 

12 ts[k]=new Thread(new AddThread()); 

13 } 

14 for(int k=0;k<10;k++){ts[k].start();} 

15 for(int k=0;k<10;k++){ts[k].join();} 

16 System.out.println(i); 

17 } 

18 } 


第 6 行 的 AtomicInteger.incrementAndGet(0) 方 法 会 使 用 CAS 操 作 将 上 自 
己 加 1， 同 时 也 会 返回 当前 值 ( 这 里 忽略 了 当前 值 )。 如 果 你 执行 这 段 
代码 ， 你 会 看 到 程序 输出 了 100000。 这 说 明 程 序 正常 执行 ， 没 有 错误 。 
如 果 不 是 线程 安全 ，i 的 值 应 该 会 小 于 100000 才 对 。 





使 用 AtomicInteger 会 比 使 用 锁具 有 更 好 的 性 能 。 出 于 篇 幅 限 制 ， 这 
里 不 再 给 出 AtomicInteger 和 锁 的 性 能 对 比 的 测试 代码 ， 相 信和 写 一 段 简单 
的 小 代码 测试 两 者 的 性 能 应 该 不 是 难事 。 这 里 让 我 们 关注 一 下 


incrementAndGet() 的 内 部 实现 (我 们 基于 JDK 1.7 分 析 ，JDK 1.8 与 1.7 的 
实现 有 所 不 同 ) 。 


1 public final int incrementAndGet() { 

2 for (;;) 4 

3 int current = get(); 

4 int next = current + 1; 

5 if (compareAndSet(current, next)) 
6 return next; 

7 } 

8 } 





其 中 get(0 方 法 非常 简单 ， 就 是 返回 内 部 数据 value。 


public final int get() { 


return value; 


这 里 让 人 映像 深刻 的 ， 应 该 是 incrementAndGet(0) 方 法 的 第 2 行 for 循 
环 吧 ! 如 果 你 是 初次 看 到 这 样 的 代码 ， 可 能 会 觉得 很 奇怪 ， 为 什么 连 设 
置 一 个 值 那么 简单 的 操作 都 需要 一 个 死 循环 呢 ? Alte: CASER 
必 是 成 功 的 ， 因 此 对 于 不 成 功 的 情况 ， 我 们 就 需要 进行 不 断 的 尝试 。 第 
3 行 的 get0 取 得 当前 值 ， 接 着 加 1 后 得 到 新 值 next。 这 里 ， 我 们 就 得 到 了 
CAS 必 需 的 两 个 参数 : 期 望 值 以 及 新 值 。 使 用 compareAndSet(0) 方 法 将 新 
值 next 写 入 ， 成 功 的 条 件 是 在 写 入 的 时 刻 ， 当 前 的 值 应 该 要 等 于 刚刚 取 
得 的 current。 如 果 不 是 这 样 ， 就 说 明 AtomicInteger 的 值 在 第 3 行 到 第 5 行 
代码 之 间 ， 又 被 其 他 线程 修改 过 了 。 当 前 线程 看 到 的 状态 就 是 一 个 过 期 
状态 。 因 此 ，compareAndSet 返 回 失败 ， 需 要 进行 下 一 次 重 试 ， 直 到 成 








功 。 


以 上 就 是 CAS 操 作 的 基本 思想 。 在 后 面 我 们 会 看 到 ， 无 论 程序 多 么 
复杂 ， 其 基本 原理 总 是 不 变 的 。 





和 AtomicImteger 类 似 的 类 还 有 AtomicLong 用 来 代表 long 型 ， 
AtomicBoolean 表 示 boolean 型 ，AtomicReference 表 示 对 象 引 用 。 


4.4.3 Java 中 的 指针 : Unsafe 类 


如 果 你 对 技术 有 痢 不 折 不 挠 的 退 求 ， 应 该 还 会 特别 在 意 
incrementAndGet() 方 法 中 compareAndSet() 的 实现 。 现 在 ， 就 让 我 们 更 进 
一 步 看 一 下 它 吧 ! 


public final boolean compareAndSet(int expect, int update) { 


return unsafe.compareAndSwapInt(this, valueOffset, expect, up 


在 这 里 ， 我 们 看 到 一 个 特殊 的 变量 unsafe， 它 是 sun.misc.Unsafe 类 
型 。 从 名 字 看 ， 这 个 类 应 该 是 封装 了 一 些 不 安全 的 操作 。 那 什么 操作 是 
不 安全 的 呢 ? 学 习 过 C 或 者 C+t+ 的 话 ， 大 家 应 该 知道 ， 指 针 是 不 安全 
的 ， 这 也 是 在 Java 中 把 指针 去 除 的 重要 原因 。 如 果 指 针 指 错 了 位 置 ， 或 
者 计算 指针 侦 移 量 时 出 错 ， 结 果 可 能 是 灾难 性 的 ， 你 很 有 可 能 会 罗 善 别 
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而 这 里 的 Unsafe 束 是 封装 了 一 些 类 似 指 针 的 操作 。 
compareAndSwapInt() 方 法 是 一 个 navtive 方 法 ， 它 的 几 个 参数 含义 如 下 : 


public final native boolean compareAndSwapInt(Object o, long offs 


第 一 个 参数 o 为 给 定 的 对 象 ，offset 为 对 象 内 的 偏 移 量 (其 实 就 是 一 
个 字段 到 对 象 尖 部 的 偏 移 量 ， 通 过 这 个 偏 移 量 可 以 快速 定位 字段 〉， 
expected 表 示 期 望 值 ，x 表 示 要 设置 的 值 。 如 果 指 定 的 字段 的 值 等 于 
expected, MARS CK E Ax. 


不 难看 出 ，compareAndSwapInt() 方 法 的 内 部 ， 必 人 然 是 使 用 CAS 原 子 
中 令 来 完成 的 。 此 外 ，Unsafe 类 还 提供 了 一 些 方法 ， 主 要 有 以 下 几 个 
《以 mt 操作 为 例 ， 其 他 数据 类 型 是 类 似 的 ) : 


// 获 得 给 定 对 象 偏 移 量 上 的 int 值 

public native int getInt(Object o, long offset); 

// 设 置 给 定 对 象 侦 移 量 上 的 int 值 

public native void putInt(Object o, long offset, int x); 
// 获 得 字段 在 对 象 中 的 偏 移 量 
public native long objectFieldOffset(Field f); 

// 设 置 给 定 对 象 的 jnt 值 ， 使 用 volatile 语 义 

public native void putIntVolatile(Object o, long offset, int x); 
// 获 得 给 定 对 象 对 象 的 int 值 ， 使 用 volatile 语 义 

public native int getIntVolatile(Object o, long offset); 

// 和 putIntVolatile( ) 一 样 ， 但 是 它 要 求 被 操作 字段 就 是 volatile 类 型 的 


public native void putorderedInt(Object o, long offset, int x); 
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的 ConcurrentLinkedQueue 实 现 ， 应 该 对 ConcurrentLinkedQueue 中 的 Node 
还 有 些 印象 。Node 的 一 些 CAS 操 作 也 都 是 使 用 Unsafe 类 来 实现 的 。 大 家 
可 以 回顾 一 下 ， 以 加 深 对 Unsafe 类 的 印象 。 


这 里 就 可 以 看 到 ， 虽 然 Java 抛 寞 了 指针 。 但 是 在 关键 时 刻 ， 类 似 指 
针 的 技术 还 是 必 不 可 少 的 。 这 里 底层 的 Unsafe 实 现 就 是 最 好 的 例子 。 但 
是 很 不 地，JDK 的 开发 人 员 并 不 希望 大 家 使 用 这 个 类 。 获 得 Unsafe 实 例 
的 方法 是 调动 其 工厂 方法 getUnsafe0 。 但 是 ， 它 的 实现 却 是 这 样 : 








public static Unsafe getUnsafe() { 
Class cc = Reflection.getCallerClass(); 
if (cc.getClassLoader() != null) 
throw new SecurityException("Unsafe") ; 


return theUnsafe; 


注意 加 粗 部 分 的 代码 ， 它 会 检查 调用 getUnsafe() 函 数 的 类 ， 如 果 这 
个 类 的 ClassLoader 不 为 null， 就 直接 抛 出 异常 ， 拒 绝 工作 。 因 此 ， 这 也 
使 得 我 们 自己 的 应 用 程序 无 法 直接 使 用 Unsafe 类 。 它 是 一 个 JDK 内 部 使 
用 的 专属 类 。 


VER: 根据 Java 类 加 载 器 的 工作 原理 ， 应 用 程序 的 类 由 App Loader 
加 载 。 而 系统 核心 类 ， 如 rt. jar 中 的 类 由 Bootstrap 类 加 载 器 加 
载 。Bootstrap 加 载 器 没有 Java 对 象 的 对 和 象 ， 因 此 试图 获得 这 个 类 
加 载 器 会 返回 nul1。 所 以 ， 当 一 个 类 的 类 加 载 器 为 nu11 时 ， 说 明 它 
是 由 Bootstrap 加 载 的 ， 而 这 个 类 也 极 有 可 能 是 rt. jar 中 的 类 。 


4.4.4 ”无 锁 的 对 象 引 用 : 


AtomicReference 


AtomicReference 和 AtomicInteger 非 常 类 似 ， 不 同 之 处 就 在 于 


AtomicInteger 是 对 整数 的 封装 ， 而 AtomicReference 则 对 应 普通 的 对 象 引 
用 。 也 惑 是 它 可 以 保证 你 在 修改 对 象 引 用 时 的 线程 安全 性 。 在 介绍 
AtomicReference 的 同时 ， 我 希望 同时 提出 一 个 有 关 原 子 操作 的 逻辑 上 的 
不 足 。 





之 前 我 们 说 过 ， 线 程 判 断 被 修改 对 象 是 否 可 以 正确 写 入 的 条 件 是 对 
象 的 当前 值 和 期 望 值 是 否 一 致 。 这 个 逻辑 从 一 般 意义 上 来 说 是 正确 的 。 
但 有 可 能 出 现 一 个 小 小 的 例外 ， 就 是 当 你 获得 对 象 当 前 数据 后 ， 在 准备 
修改 为 新 值 前 ， 对 象 的 值 被 其 他 线程 连续 修改 了 两 次 ， 而 经 过 这 两 次 修 
改 后 ， 对 象 的 值 义 恢复 为 旧 值 。 这 样 ， 当 前 线程 就 无 法 正确 判断 这 个 对 
象 完 竟 是 否 被 修改 过 。 如 图 4.2 所 示 ， 显 示 了 这 种 情况 。 
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图 4.2 对 象 值 被 反复 修改 回 原 数据 








一 般 来 说 ， 发 生 这 种 情况 的 概率 很 小 。 而 且 即 使 发 生 了 ， 可 能 也 不 
征 什么 大 问题 。 比 如 ， 我 们 只 是 简单 地 要 做 一 个 数值 加 法 ， 即 使 在 我 取 
得 期 望 值 后 ， 这 个 数字 被 不 断 的 修改 ， 只 要 它 最 终 改 回 了 我 的 期 望 值 ， 
我 的 加 法 计算 就 不 会 出 错 。 也 惑 是 说 ， 当 你 修改 的 对 象 没有 过 程 的 状态 








言 息 ， 所 有 的 信息 都 只 保存 于 对 象 的 数值 本 身 。 








但 是 ， 在 现实 中 ， 还 可 能 存在 另外 一 种 场景 ， 束 是 我 们 是 否 能 修改 
对 象 的 值 ， 不 仅 取 决 于 当前 值 ， 还 和 对 象 的 过 程 变 化 有 关 ， 这 时 ， 
AtomicReference 就 无 能 为 力 了 。 


打 一 个 比方 ， 如 打 有 一 家 香 糕 店 ， 为 了 挽留 客户 ， 决 定 为 贵宾 卡 里 
余额 小 于 20 元 的 客户 一 次 性 赠送 20 元 ， 刺 激 消 费 者 充值 和 消费 。 但 条 件 
是 ， 每 一 位 客户 只 能 被 赠 送 一 次 。 





现在 ， 我 们 就 来 模拟 这 个 场景 ， 为 了 演示 AtomicReference， 我 在 这 
里 使 用 AtomicReference 实 现 这 个 功能 。 首 先 ， 我 们 模拟 用 户 账 户 余 额 。 


定义 用 户 账户 余额 : 


static AtomicReference<Integer> money=new AtomicReference<Integ 
// 设置 账户 初始 值 小 于 20， 显 然 这 是 一 个 需要 被 充值 的 账户 
money.set(19); 








RE, Rima TAGE, EMAAR, FPA A 
件 的 客户 充值 。 


91 // 模 拟 多 个 线程 同时 更 新 后 台数 据 库 ， 为 用 户 充 值 


02 ron (amt e Or 


03 new Thread() { 

04 public void run() { 
05 while(true){ 

06 while(true){ 


07 Integer m=money.get(); 


08 if (m<20){ 

09 if(money.compareAndSet(m, m+20)){ 

10 System.out.println(" 余 额 小 于 20 元 ， 充 值 成 功 ， 余 额 
11 break; 

12 } 

13 yelse{ 

14 //System.out.println(" 余 额 大 于 20 元 ， 无 须 3 
15 break ; 


19 } 
20 }.start(); 


上 述 代码 第 8 行 ， 判 断 用 户 余 额 并 给 予 赠送 金额 。 如 果 已 经 被 其 他 
用 户 处 理 ， 那 么 当前 线程 就 会 失败 。 因 此 ， 可 以 确保 用 户 只 会 被 充值 一 
次 。 





此 时 ， 如 果 很 不 位， 用 户 正 好 正在 进行 消费 ， 就 在 赠 予 金额 到 账 的 
同时 ， 他 进行 了 一 次 消费 ， 使 得 总 金额 又 小 于 20 元 ， 并 且 正 好 累计 消费 
了 20 元 。 使 得 消费 、 赠 予 后 的 金额 等 于 消费 前 、 赠 予 前 的 金额 。 这 时 ， 
后 台 的 赠 予 进程 就 会 误 以 为 这 个 账户 还 没有 赠 予 ， 所 以 ， 存 在 被 多 次 赠 
予 的 可 能 。 下 面 模拟 了 这 个 消费 线程 : 

01 // 用 户 消费 线程 ， 模 拟 消费 行 为 
02 new Thread() { 


03 public void run() { 


04 for(int i=0;i<100;i++){ 


05 while(true){ 

06 Integer m=money.get(); 

07 if (m>10){ 

08 System.out.println("X1070"); 

09 if (money .compareAndSet(m, m-10)){ 

10 System.out.println(" 成 功 消费 10 元 ， 余 额 : "+ 
11 break; 

12 } 

13 yelse{ 

14 System.out.printlLn(" 没 有 足够 的 金额 ") ， 

15 break; 

16 } 

17 } 

18 try {Thread.sleep(100);} catch (InterruptedExcepti 
19 } 

20 } 


21 }.start(); 





上 述 代 码 中 ， 消 费 者 只 要 贯 宾 卡 里 的 钱 大 于 10 元 ， 就 会 立即 进行 一 
次 10 元 的 消费 。 执 行 上 述 程 夺 ， 得 到 的 输出 如 下 : 


余额 小 于 20 元 ， 充 值 成 功 ， 余 额 :39 元 


大 于 10 元 
成 功 消费 10 元 ， 余 额 :29 
大 于 10 元 


成 功 消费 10 元 ， 余 额 :19 


余额 小 于 20 元 ， 充 值 成 功 ， 余 额 :39 元 


大 于 10 元 
成 功 消费 10 元 ， 余 额 :29 
大 于 10 元 


成 功 消费 10 元 ， 人 余额:39 
余额 小 于 20 元 ， 充 值 成 功 ， 余 额 :39 元 








从 这 一 段 输 出 中 ， 可 以 看 到 ， 这 个 账户 被 完 后 反复 多 次 充值 。 其 原 
因 正 是 因为 账户 余额 被 反复 修改 ， 修 改 后 的 值 等 于 原 有 的 数值 ， 使 得 
CAS 操 作 无 法 正确 判断 当前 数据 状态 。 


虽然 说 这 种 情况 出 现 的 概率 不 大 ， 但 是 依然 是 有 可 能 出 现 的 。 
此 ， 当 业务 上 确实 可 能 出 现 这 种 情况 时 ， 我 们 也 必须 多 加 防范 。 体 贴 的 
JDK 也 已 经 为 我 们 考虑 到 了 这 种 情况 ， 使 用 AtomicStampedReference 就 
可 以 很 好 地 解决 这 个 问题 。 


4.4.5 ”市 有 时 间 惟 的 对 象 引 用 : 


AtomicStampedReference 





AtomicReference 无 法 解决 上 述 问 题 的 根本 因为 是 对 象 在 修改 过 程 
中 ， 丢 失 了 状态 信息 。 对 象 值 本 身 与 状态 被 画 上 了 等 号 。 因 此 ， 我 们 只 
要 能 够 记录 对 象 在 修改 过 程 中 的 状态 值 ， 束 可 以 很 好 地 解决 对 象 被 反复 
修改 导致 线程 无 法 正确 判断 对 象 状态 的 问题 。 








AtomicStampedReference 正 是 这 么 做 的 。 它 内 部 不 仅 维护 了 对 象 
值 ， 还 维护 了 一 个 时 间 惟 〈 我 这 里 把 它 称 为 时 间 戳 ， 实 际 上 它 可 以 使 任 
何 一 个 整数 来 表示 状态 值 ) 。 当 AtomicStampedReference 对 应 的 数值 被 


修改 时 ， 除 了 更 新 数据 本 映 外 ， 还 必须 要 更 新 时 间 戳 。 当 
AtomicStampedReference 设 置 对 象 值 时 ， 对 象 值 以 及 时 间 惟 都 必须 满足 
期 望 值 ， 写 入 才 会 成 功 。 因 此 ， 即 使 对 象 值 被 反复 读 写 ， 写 回 原 值 ， 只 
要 时 间 惟 发 生变 化 ， 就 能 防止 不 恰当 的 写 入 。 








AtomicStampedReference 的 几 个 API 在 AtomicReference 的 基础 上 新 
增 了 有 关 时 间 惟 的 信息 : 


// 比 较 设置 参数 依次 为 : 期 望 值 写 入 新 值 期 望 时间 惟 Sry Tel ak 
public boolean compareAndSet(V expectedReference, V 
newReference, int expectedStamp,int newStamp) 

// 获 得 当前 对 象 引 用 

public V getReference() 

// 获 得 当前 时 间 惟 

public int getStamp() 

// RA HT RG] FA ANY TK 


public void set(V newReference, int newStamp) 





有 了 AtomicStampedReference 这 个 法 宝 ， 我 们 就 再 也 不 用 担心 对 象 
被 写 坏 啦 ! 现在 ， 就 让 我 们 使 用 AtomicStampedReference 来 修正 那个 贵 
宾 卡 充值 的 问题 : 


01 public class AtomicStampedReferenceDemo { 


02 static AtomicStampedReference<Integer> money=new AtomicStampe 


03 public static void main(String[] args) { 
04 // 模 拟 多 个 线程 同时 更 新 后 台数 据 库 ， 为 用 户 充 值 
05 ror(ime 12 05 1< 3 7 1r) A 


06 final int timestamp=money.getStamp(); 


07 
08 
09 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 
32 
33 


new Thread() { 
public void run() { 
while(true) { 
while(true) { 
Integer m=money.getReference(); 
if (m<20){ 
if (money.compareAndSet(m, m+20,timest 
System.out.println(" 余 额 小 于 20 元 ， 充 值 成 功 ， 余 额 :"+money 
break; 
} 
selse{ 
//System.out .println(" 余 额 大 于 2( 


break ; 


} 
}.start(); 


// 用 户 消费 线程 ， 模 拟 消费 行为 
new Thread() { 
public void run() { 
for(int i=0;i<100;i++){ 
while(true) { 
int timestamp=money.getStamp(); 


Integer m=money.getReference(); 


34 if(m>10){ 


35 System.out.printin("X¥107t"); 

36 if(money.compareAndSet(m, m-10, times 
37 System.out.println( "MIA #1070, RA: "+n 
38 break; 

39 b 

40 }elsef 

41 System.out .println(" 没 有 足够 的 金额 ")， 
42 break; 

43 } 

44 } 

45 try {Thread.sleep(100);} catch (Interrupte 
46 } 

47 } 

48 }.start(); 

49 } 

50 } 


第 2 行 ， 我 们 使 用 AtomicStampedReference 代 蔡 原 来 的 
AtomicReference。 第 6 行 获得 账户 的 时 间 戳 ， 后 续 的 赠 予 操作 以 这 个 时 
间 惟 为 依据 。 如 果 赠 予 成 功 〈 第 13 行 ) ， 则 修改 时 间 惟 ， 使 得 系统 不 可 
能 上 肥 生 二 次 赠 予 的 情况 。 消 费 线 程 也 是 类 似 ， 每 次 操作 ， 都 使 得 时 间 戳 
加 1《〈 第 36 行 ) ， 使 之 不 可 能 重复 。 


执行 上 述 代 码 ， 可 以 得 到 以 下 输出 : 


余额 小 于 20 元 ， 充 值 成 功 ， 余 额 :39 元 
大 于 10 元 


成 功 消 费 10 元 ， 余 额 :29 
大 于 10 元 

成 功 消 费 10 元 ， 余 额 :19 
大 于 10 元 

成 功 消费 10 元 ， 余 额 :9 
没有 足够 的 金额 


可 以 看 到 ， 上 账户 只 被 赠 予 了 一 次 。 


AtomicIntegerArray 


除了 提供 基本 数据 类 型 外 ，JDK 还 为 我 们 准备 了 数组 等 复合 结构 。 
当前 可 用 的 原子 数组 有 : AtomicIntegerArray、AtomicLongArray 和 
AtomicReferenceArray， 分 别 表示 整数 数组 、long 型 数组 和 普通 的 对 象 数 
组 。 


这 里 以 AtomicIntegerArray 为 例 ， 展 示 原 子 数 组 的 使 用 方式 。 


AtomicIntegerArray 本 质 上 是 对 int[] 类 型 的 封装， 使 用 Unsafe 类 通过 
CAS 的 方式 控制 int[] 在 多 线程 下 的 安全 性 。 它 提供 了 以 下 几 个 核心 
API: 


// 获 得 数组 第 i 个 下 标的 元 素 
public final int get(int i) 
// 获 得 数组 的 长 度 

public final int length() 


// 将 数组 第 i 个 下 标 设置 为 newValue， 并 返回 旧 的 值 

public final int getAndSet(int i, int newValue) 

// 进 行 CAS 操 作 ， 如 果 第 i 个 下 标的 元 素 等 于 expect， 则 设置 为 update， 设 置 成 功 返 回 1 
public final boolean compareAndSet(int i, int expect, int update) 
// 将 第 i 个 下 标的 元 素 加 1 

public final int getAndIncrement(int i) 

// 将 第 i 个 下 标的 元 素 减 1 

public final int getAndDecrement(int i) 

// 将 第 i 个 下 标的 元 素 增 加 delta (delta 可 以 是 负数 ) 

public final int getAndAdd(int i, int delta) 

















下 面 给 出 一 个 简单 的 示例 ， 展 示 AtomicIntegerArray 的 使 用 : 


01 public class AtomicIntegerArrayDemo { 


02 static AtomicIntegerArray arr = new AtomicIntegerArray(10) 
03 public static class AddThread implements Runnable{ 

04 public void run(){ 

05 for(int k=0;k<10000; k++) 

06 arr.getAndIncrement(k%arr.length()); 

07 } 

08 } 

09 public static void main(String[] args) throws InterruptedE 
10 Thread[] ts=new Thread[10]; 

11 for(int k=0;k<10;k++){ 

12 ts[k]=new Thread(new AddThread()); 

13 } 


14 for(int k=0;k<10;k++){ts[k].start();} 


15 for(int k=0;k<10;k++){ts[k].join();} 


16 System.out.printlin(arr); 


上 述 代码 第 2 行 ， 申 明了 一 个 内 含 10 个 元 素 的 数组 。 第 3 行 定义 的 线 
程 对 数组 内 10 个 元 素 进行 累加 操作 ， 每 个 元 素 各 加 1000 次 。 第 11 行 ， 开 
启 10 个 这 样 的 线程 。 因 此 ， 可 以 预测 ， 如 果 线 程 安 全 ， 数 组 内 10 个 元 素 
的 值 必然 都 是 10000。 反 之 ， 如 果 线 程 不 安全 ， 则 部 分 或 者 全 部 数值 会 
小 于 10000。 


程序 的 输出 结果 如 下 : 


[10000, 10000, 10000, 10000, 10000, 10000, 10000, 10000, 10000, 1 


这 说 明 AtomicIntegerArray 确 实 合理 地 保证 了 数组 的 线程 安全 性 。 


4.4.7 ”让 普通 变量 也 至 受 原 子 操作 : 
AtomicIntegerFieldUpdater 


有 时 候 ， 由 于 初期 考虑 不 周 ， 或 者 后 期 的 需求 变化 ， 一 些 普通 变量 
可 能 也 会 有 线程 安全 的 需求 。 如 果 改 动 不 大 ， 我 们 可 以 简单 地 修改 程序 
中 每 一 个 使 用 或 者 读 取 这 个 变量 的 地 方 。 但 显然 ， 这 样 并 不 符合 软件 设 
计 中 的 一 条 重要 原则 一 一 开 闭 原则 。 也 就 是 系统 对 功能 的 增加 应 该 是 开 
放 的 ， 而 对 修改 应 该 是 相对 保守 的 。 而 且 ， 如 果 系 统 里 使 用 到 这 个 变量 
的 地 方 特别 多 ， 一 个 一 个 修改 也 是 一 件 令 人 厌烦 的 事情 (况且 很 多 使 用 
场景 下 可 能 只 是 只 读 的 ， 并 无 线程 安全 的 强烈 要 求 ， 完 全 可 以 保持 原 

















样 ) 。 





如 有 果 你 有 这 种 困扰 ， 在 这 里 根本 不 需要 担心 ， 因 为 在 原子 包 里 还 有 
一 个 实用 的 工具 类 AtomicIntegerFieldUpdater。 它 可 以 让 你 在 不 改动 (或 
者 极 少 改动 ) 原 有 代码 的 基础 上 ， 让 普通 的 变量 也 享受 CAS 操 作 带 来 的 
线程 安全 性 ， 这 样 你 可 以 修改 极 少 的 代码 ， 来 获得 线程 安全 的 保证 。 这 
听 起 来 是 不 是 让 人 很 激动 呢 ? 


根据 数据 类 型 不 同 ， 这 个 Updater 有 三 种 ， 分 别 是 
AtomicIntegerFieldUpdater、 AtomicLong- FieldUpdater 和 
AtomicReferenceFieldUpdater。 顾 名 思 义 ， 它 们 分 别 可 以 对 int、long 和 普 
通 对 象 进 行 CAS 修 改 。 


现在 来 思考 这 么 一 个 场景 。 假 设 某 地 要 进行 一 次 选举 。 现 在 模拟 这 
个 投票 场景 ， 如 果 选 氏 投 了 候选 人 一 票 ， 就 记 为 1， 人 否则 记 为 0。 节 终 的 
选票 显然 就 是 所 有 数据 的 简单 求 和 。 


01 public class AtomicIntegerFieldUpdaterDemo { 


02 public static class Candidate{ 

03 int id; 

04 volatile int score; 

05 } 

06 public final static AtomicIntegerFieldUpdater <Candidate> 
07 = AtomicIntegerFieldUpdater .newUpdater (Candidate.class 
08 // 检 查 Updater 是 否 工作 正确 

09 public static AtomicInteger allScore=new AtomicInteger(0); 
10 public static void main(String[] args) throws InterruptedE 


11 final Candidate stu=new Candidate(); 


12 Thread[] t=new Thread[10000]; 


13 FORCING =) 0; 1 < 10000 p 1r) { 

14 t[i]=new Thread() { 

15 public void run() { 

16 if(Math.random()>0.4){ 

17 scoreUpdater.incrementAndGet (stu); 
18 allScore.incrementAndGet(); 

19 } 

20 } 

21 }; 

22 t[i].start(); 

23 } 

24 for(int i = 0 ; i < 10000 ; i++) { tla] join() 
25 System.out.println("score="+stu.score); 

26 System.out.println("allScore="+allScore); 

27 } 

28 } 





上 述 代码 模拟 了 这 个 计 标 场景， 候选 人 的 得 票数 量 记 录 在 
Candidate.score 中 。 注 意 ， 它 是 一 个 普通 的 volatile 变 量 。 而 volatile 变 量 
并 不 是 线程 安全 的 。 第 6 一 7 行 定义 了 AtomicIntegerFieldUpdater 实 例 ， 用 
来 对 Candidate.score 进 行 号 入 。 而 后 续 的 allScore 我 们 用 来 检查 
AtomicIntegerFieldUpdater 的 正确 性 。 如 果 AtomicIntegerFieldUpdater 真 
的 保证 了 线程 安全 ， 那 么 最 终 Candidate.score 和 allScore 的 值 必然 是 相等 
的 。 和 否则， 就 说 明 AtomicIntegerFieldUpdater 根 本 没有 确保 线程 安全 的 写 
入 。 第 12 一 21 行 模拟 了 计 票 过 程 ， 这 里 假设 有 大 约 60% 的 人 投 赞 成 票 ， 
并 且 投 票 是 随机 进行 的 。 第 17 行 使 用 Updater 修 改 Candidate.score〈 这 里 





应 该 是 线程 安全 的 ) ， 第 18 行 使 用 AtomicInteger 计 数 ， 作 为 参考 基准 。 


大 家 如 果 运 行 这 段 程 序 ， 不 难 发 现 ， 最 终 的 Candidate.score 总 是 和 
allScore 绝 对 相等 。 这 说 明 AtomicIntegerFieldUpdater 很 好 地 保证 了 
Candidate.score 的 线程 安全 。 








虽然 AtomicIntegerFieldUpdater 很 好 用 ， 但 是 还 是 有 几 个 注意 事项 : 





第 一 ，Updater 只 能 修改 它 可 见 范 围 内 的 变量 。 因 为 Updater 使 用 反 
射 得 到 这 个 变量 。 如 果 变 量 不 可 见 ， 束 会 出 错 。 比 如 如 果 score 申 明 为 
private， 就 是 不 可 行 的 。 








第 二 ， 为 了 确保 变量 被 正确 的 读 取 ， 它 必须 是 volatile 类 型 的 。 如 果 
我 们 原 有 代码 中 未 申明 这 个 类 型 ， 那 么 简单 地 申明 一 下 就 行 ， 这 不 会 引 
起 什么 问题 。 











第 三 ， 由 于 CAS 操 作 会 通过 对 象 实 例 中 的 偏 移 量 直接 进行 赋值 ， 
此 ， 它 不 支持 static 字 段 (Unsafe. objectFieldOffset() 不 支持 静态 变量 ) 。 


好 了 ， 通 过 AtomicIntegerFieldUpdater， 是 不 是 让 我 们 可 以 更 加 随心 
所 欲 地 对 系统 关键 数据 进行 线程 安全 的 保护 呢 ? 


4.4.8 ”挑战 无 锁 算 法 : 无 锁 的 Vector 
实现 
我 们 已 经 比较 完整 地 介绍 了 有 关 无 锁 的 概念 和 使 用 方法 。 相 对 于 有 


锁 的 方法 ， 使 用 无 锁 的 方式 编程 更 加 考验 一 个 程序 员 的 耐心 和 智力 。 但 
是 ， 无 锁 带 来 的 好 处 也 是 显而易见 的 ， 第 一 ， 在 高 并 发 的 情况 下 ， 它 比 





有 锁 的 程序 拥有 更 好 的 性 能 ， 第 二 ， 它 天 生 就 是 死 锁 免疫 的 。 束 凭借 这 
两 个 优势 ， 束 值得 我 们 冒险 尝试 使 用 无 锁 的 并 发 。 


这 里 ， 我 想 同 大 家 介绍 一 种 使 用 无 锁 方 式 实 现 的 Vector。 通 过 这 个 
案例 ， 我 们 可 以 更 加 深刻 地 认识 无 锁 的 算法 ， 同 时 也 可 以 学 习 一 下 有 关 
Vector 实现 的 细节 和 算法 技巧 《在 本 例 中 ， 讲 述 的 无 锁 Vector 来 自 于 
amino 并 发 包 ) 。 


我 们 将 这 个 无 锁 的 Vector 称 为 LockFreeVector。 它 的 特点 是 可 以 根 
据 需 求 动态 扩展 其 内 部 空间 。 在 这 里 ， 我 们 使 用 二 维 数组 来 表示 
LockFreeVector 的 内 部 存储 ， 如 下 : 











private final AtomicReferenceArray<AtomicReferenceArray<E>> bu 


变量 buckets 存 放 所 有 的 内 部 元 素 。 从 定义 上 看 ， 它 是 一 个 保存 着 数 
组 的 数组 ， 也 就 是 通常 的 二 维 数组 。 特 别 之 处 在 于 这 些 数组 都 是 使 用 
CAS 的 原子 数组 。 为 什么 使 用 二 维 数组 去 实现 一 个 一 维 的 Vector 呢 ? 这 
是 为 了 将 来 Vector 进行 动态 扩展 时 可 以 更 加 方便 。 我 们 知道 ， 
AtomicReferenceArray 内 部 使 用 Object[] 来 进行 实际 数据 的 存储 ， 这 使 得 
动态 空间 增加 特别 的 麻烦 ， 因 此 使 用 二 维 数组 的 好 处 就 是 为 了 将 来 可 以 
方便 地 增加 新 的 元 素 。 








此 外 ， 为 了 更 有 序 的 读 写 数组 ， 定 义 一 个 称 为 Descriptor 的 元 素 。 
它 的 作用 是 使 用 CAS 操 作 写 入 新 数据 。 


01 static class Descriptor<E> { 
02 public int size; 
03 volatile WriteDescriptor<E> writeop; 


04 public Descriptor(int size, WriteDescriptor<E> writeop) { 


05 
06 
07 
08 
09 
10 
11 
12 
13 
14 
15 
16 
Ay 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 


public void completeWrite() { 


WriteDescriptor<E> tmpOp 


size = size; 


writeop = writeop; 


if (tmpOp != null) { 


tmpOp.doIt(); 


writeop = null; // this is safe since all write to 


// null as r_value. 


static class WriteDescriptor<E> { 


oldv; 


newV; 


writeop; 


public AtomicReferenceArray<E> addr; 


public int addr_ind; 


public WriteDescriptor(AtomicReferenceArray<E> addr, int 


E oldV, E newV) { 


this. 
this. 

} 
} 

} 

} 

public E 

public E 
this. 
this. 


this. 


this. 


addr = addr; 
addr_ind = addr_ind; 
oldV = oldV; 


newV = newV; 


32 public void doIt() { 
33 addr.compareAndSet(addr_ind, oldV, newV); 
34 } 


上 述 代码 第 4 行 定 义 的 Descriptor 构 造 函数 接收 两 个 参数 ， 第 一 个 为 
| 第 2 个 为 一 个 writer。 最 终 ， 写 入 数据 是 通过 writer 进 
行 的 〈 通 过 completeWrite() 方 法 ) 。 


第 24 行 ，WriteDescriptor 的 构造 函数 接收 四 个 参数 。 第 一 个 ee 
addr 表 示 要 修改 的 原子 数组 ， 第 二 个 参数 为 要 写 入 的 数组 索引 位 置 ， 
三 个 oldV 为 期 望 值 ， 第 四 个 newV 为 需要 写 入 的 值 。 


在 构造 LockFreeVector 时 ， 显 然 需 要 将 buckets 和 descriptor 进 行 初 始 
化 8 


public LockFreeVector() { 
buckets = new AtomicReferenceArray<AtomicReferenceArray<E>> 
buckets.set(0, new AtomicReferenceArray<E>(FIRST_BUCKET_SIZE 
descriptor = new AtomicReference<Descriptor<E>->(new Descril 


null) ); 


在 这 里 N_BUCKET 为 30, 也 就 是 说 这 个 buckets 里 面 可 以 存放 一 共 30 
个 数组 〈 由 于 数组 无 法 动态 增长 ， 因 此 数组 总 数 也 就 不 能 超过 30 个 ) 。 
并 且 将 第 一 个 数组 的 大 小 FIRST_BUCKET_SIZE 设 为 8。 到 这 里 ， 大 家 
可 能 会 有 一 个 疑问 ， 如 果 每 个 数组 8 个 元 素 ， 一 共 30 个 数组 ， 那 岂 不 是 
一 共 只 能 存放 240 个 元 素 吗 ? 


如 果 大 家 了 解 JDK 内 的 Vector 实现 ， 应 该 知道 ，Vector 在 进行 空间 
增长 时 ， 默 认 情 况 下 ， 每 次 都 会 将 总 容量 翻 倍 。 因 此 ， 这 里 也 借鉴 类 似 
的 思想 ， 每 次 空间 扩张 ， 新 的 数组 的 大 小 为 原来 的 两 倍 〈( 即 每 次 空间 扩 
展 都 司 用 一 个 新 的 数组 ) ， 因 此 ， 第 一 个 数组 为 8， 第 二 个 就 是 16， 第 
三 个 就 是 32。 依 此 类 推 ， 因 此 30 个 数组 可 以 文 持 的 总 元 系 达 到 =9 。 





这 数值 已 经 超过 了 2^33， 即 在 80 亿 以 上 。 因 此 ， 可 以 满足 一 般 的 应 
用 。 


当 有 元 素 需 要 加 入 LockFreeVector 时 ， 使 用 一 个 名 为 push_backO 的 
方法 ， 将 元 素 压 入 Vector 最 后 一 个 位 置 。 这 个 操作 显然 束 是 
LockFreeVector 的 最 为 核心 的 方法 ， 也 是 最 能 体现 CAS 使 用 特点 的 方 
法 ， 它 的 实现 如 下 : 


01 public void push back(E e) { 


02 Descriptor<E> desc; 

03 Descriptor<E> newd; 

04 do { 

05 desc = descriptor.get(); 

06 desc.completewrite(); 

07 

08 int pos = desc.size + FIRST_BUCKET_SIZE; 

09 int zeroNumPos = Integer .numberOfLeadingZeros(pos); 
10 int bucketInd = zeroNumFirst - zeroNumPos; 

11 if (buckets.get(bucketInd) == null) { 

12 int newLen = 2 * buckets.get(bucketInd - 1).length 
13 if (debug) 


14 System.out.printin("New Length is:" + newLen); 


i5 buckets.compareAndSet(bucketInd, null, 


16 new AtomicReferenceArray<E>(newLen) ); 

17 } 

18 

19 int idx = (0x80000000>>>zeroNumPos) ^ pos; 

20 newd = new Descriptor<E>(desc.size + 1, new WriteDesc 
21 buckets.get(bucketInd), idx, null, e)); 

22 } while (!descriptor.compareAndSet(desc, newd)); 

23 descriptor.get().completewrite(); 

24 } 


可 以 看 到 ， 这 个 方法 主体 部 分 是 一 个 do-while 循 环 ， 用 来 不 断 尝试 
对 descriptor 的 设置 。 也 就 是 通过 CAS 保 证 了 descriptor 的 一 致 性 和 安全 
性 。 在 第 23 行 ， 使 用 descriptor 将 数据 真正 地 写 入 数组 中 。 这 个 descriptor 
写 入 的 数据 由 第 20 一 21 行 构造 的 WriteDescriptor 决 定 。 


在 循环 最 开始 (第 5 行 )， 使 用 descriptor 先 将 数据 写 入 数组 ， 是 为 
了 防止 上 一 个 线程 设置 完 descriptor 后 (第 22 行 ) ， 还 没 来 得 及 执行 第 23 
行 的 写 入 ， 因 此 ， 做 一 次 预防 性 的 操作 。 





因为 限制 要 将 元 素 e 压 入 Vector， 因 此 ， 我 们 必须 首先 知道 这 个 e 应 
该 放 在 哪个 位 置 。 由 于 目前 使 用 了 二 维 数组 ， 因 此 我 们 自然 需要 知道 e 
所 在 哪个 数组 (buckets 中 的 下 标 位 置 ) 和 数组 中 的 下 标 。 


第 8 一 10 行 通过 当前 Vector 的 大 小 〈desc.size) ， 计 算 新 的 元 素 应 该 
洲 入 哪个 数组 。 这 里 使 用 了 位 运算 进行 计算 。 


之 前 说 过 ，LockFreeVector 每 次 都 会 成 倍 的 扩容 。 它 的 第 1 个 数组 长 


度 为 8， 第 2 个 就 是 16， 第 3 个 就 是 32， 依 此 类 推 。 它 们 的 二 进 制 表示 如 
下 


00000000 00000000 00000000 00001000: 第 一 个 数组 大 小 ，28 个 


。 00000000 00000000 00000000 00010000: 第 二 个 数组 大 小 ，27 个 
。 00000000 00000000 00000000 00100000: 第 三 个 数组 大 小 ，26 个 
。 00000000 00000000 00000000 01000000: 第 四 个 数组 大 小 ，25 个 


它们 之 和 就 是 整个 LockFreeVector 的 总 大 小 ， 因 此 ， 如 果 每 一 个 数 
组 都 恰好 填 满 ， 那 么 总 大 小 应 该 类 似 如 下 的 数值 〈 以 4 个 数组 填 满 为 
例 ) 。 


e 00000000 00000000 00000000 01111000: 4 个 数组 都 恰好 填 满 时 
的 大 小 。 


导致 这 个 数字 进位 的 最 小 条 件 ， 就 是 加 上 二 进 制 的 1000。 而 这 个 数 
字 正 好 是 8 (FIRST_BUCKET_SIZE 就 是 8) 。 这 就 是 第 8 行 代 码 的 意 
义 。 它 可 以 使 得 数组 大 小 发 生 一 次 二 进 制 的 进位 (如 果 不 进位 说 明 还 在 
第 一 个 数组 中 ) ， 进 位 后 前 导 零 的 数量 就 会 发 生变 化 。 而 元 素 所 在 的 数 
组 ， 和 pos (第 8 行 定义 的 变量 ) 的 前 导 零 直接 相关 。 每 进行 一 次 数组 扩 
容 ， 它 的 前 导 零 就 会 减 1。 如 果 从 来 没有 扩容 过 ， 它 的 前 导 零 就 是 28 
个 。 以 后 ， 逐 级 减 1。 这 就 是 第 9 行 获得 pos 前 导 零 的 原因 。 第 10 行 ， 通 
过 pos 的 前 导 零 可 以 立即 定位 使 用 哪个 数组 〈 也 就 是 得 到 了 bucketInd 的 
IE ia 























第 11 行 ， 判 断 这 个 数组 是 否 存在 。 如 果 不 存 在 ， 则 创建 这 个 数组 ， 
大 小 为 前 一 个 数组 的 两 倍 ， 并 把 它 设 置 到 buckets 中 。 








接着 再 看 一 下 元 素 没 有 愉 好 填 满 的 情况 。 


00000000 00000000 00000000 00001000: 第 一 个 数组 大 小 ，28 个 


e 00000000 00000000 00000000 00010000: 第 二 个 数组 大 小 ，27 个 

e 00000000 00000000 00000000 00100000: 第 三 个 数组 大 小 ，26 个 

e 00000000 00000000 00000000 00000001: 第 四 个 数组 大 小 ， 只 有 
一 个 元 素 。 

那么 总 大 小 如 下 。 

e 00000000 00000000 00000000 00111001: 元 素 总 个 数 。 


总 个 数 加 上 二 进 制 1000 后 ， 得 到 : 


e 00000000 00000000 00000000 01000001 
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元 素 在 当前 数组 内 的 偏 移 量 (也 就 是 数组 下 标 ，。 根 据 这 个 理论 ， 我 们 
束 可 以 通过 pos 计 算 这 个 元 系 应 该 放 在 给 定数 组 的 哪个 位 置 。 通 过 第 19 
行 代码 ， 获 得 pos 的 除了 第 一 位 数字 1 以 外 的 其 他 位 的 数值 。 因 此 ，pos 
的 前 导 零 可 以 表示 元 素 所 在 的 数组 ， 而 pos 的 后 面 几 位 ， 则 表示 元 素 所 
在 这 个 数组 中 的 位 置 。 由 此 ， 第 19 行 代码 就 取得 了 元 素 的 所 在 位 置 
idx. 














到 此 ， 我 们 就 已 经 得 到 新 元 素 位 置 的 全 部 信息 ， 剩 下 的 就 是 将 这 些 
ee So E E He ne 这 里 ， 
就 通 过 CAS 操 作 ， 保 证 写 入 正确 性 。 








下 面 来 看 一 下 get0 操 作 的 实现 ; 


1 @Override 


2 public E get(int index) { 


3 int pos = index + FIRST_BUCKET_SIZE; 

4 int zeroNumPos = Integer.numberOfLeadingZeros(pos)j; 
5 int bucketInd = zeroNumFirst - zeroNumPos; 

6 int idx = (0x80000000>>>zeroNumPos) ^ pos; 

7 return buckets.get(bucketInd).get(idx); 

8 } 
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以 及 数组 中 的 索引 下 标 。 这 里 简单 地 通过 buckets 定 位 到 对 应 的 元 素 即 
可 。 


这 样 ， 对 于 Vector 来 说 两 个 重要 的 方法 就 已 经 实现 了 。 其 他 方法 也 
是 非常 类 似 的 ， 这 里 就 不 再 详细 讨论 了 。 

449 ”让 线程 之 间 互 相 帮 助 : AG 
SynchronousQueue 的 实现 


在 对 线程 池 的 介绍 中 ， 提 到 了 一 个 非常 特殊 的 等 待 队 列 
SynchronousQueue。SynchronousQueue 的 容量 为 0， 任 何 一 个 对 


SynchronousQueue 的 写 需 要 等 待 一 个 对 SynchronousQueue 的 读 ， 反 之 亦 
然 。 因 此 ，SynchronousQueue 与 其 说 是 一 个 队列 ， 不 如 说 是 一 个 数据 交 
换 通道 。 那 SynchronousQueue 的 奇妙 功能 是 如 何 实现 的 呢 ? 





既然 我 打算 在 这 一 节 中 介绍 它 ， 那 么 SynchronousQueue 束 和 无 锁 的 
操作 脱离 不 了 关系 。 实 际 上 SynchronousQueue 内 部 也 正 是 大 量 使 用 了 无 
锁 工 具 。 


对 SynchronousQueue 来 说 ， 它 将 putO0 和 take0) 两 个 功能 截然 不 同 的 操 
作 抽 象 为 一 个 共通 的 方法 Transferer.transfer0。 从 字面 上 看 ， 这 就 是 数据 
传递 的 意思 。 它 的 完整 签名 如 下 : 


Object transfer(Object e, boolean timed, long nanos) 


当 参 数 e 为 非 空 时 ， 表 示 当 前 操作 传递 给 一 个 消费 者 ， 如 果 为 空 ， 
则 表示 当前 操作 需要 请 求 一 个 数据 。timed 参 数 决 定 是 否 存在 timeout 时 
间 ，nanos 决 定 了 timeout 的 时 长 。 如 果 返 回 值 非 空 ， 则 表示 数据 已 经 接 
受 或 者 正常 提供 ， 如 果 为 空 ， 则 表示 失败 〈 超 时 或 者 中 断 ) 。 








SynchronousQueue 内 部 会 维护 一 个 线程 等 竺 队列 。 等 竺 队列 中 会 保 
存 等 待 线程 以 及 相关 数据 的 信息 。 比 如 ， 生 产 者 将 数据 放 入 
SynchronousQueue 时 ， 如 果 没 有 消费 者 接收 ， 那 么 数据 本 号 和 线程 对 象 
都 会 打包 在 队列 中 等 待 〈 因 为 SynchronousQueue 容 积 为 0， 没 有 数据 可 
以 正常 放 入 ) o 


Transferer.transferO 函 数 的 实现 是 SynchronousQueue 的 核心 ， 它 大 体 
下 分 为 三 个 步骤 : 


L 如 条 等 竺 队列 为 空 ， 或 者 队列 中 节点 的 类 型 和 本 次 操作 是 一 臻 


的 ， 那 么 将 当前 操作 压 入 队列 等 待 。 比 如 ， 等 待 队列 中 是 读 线程 
等 待 ， 本 次 操作 也 是 该 ， 因 此 这 两 个 读 都 需要 等 待 。 进 入 等 待 队 


列 的 线程 可 能 会 被 挂 起 ， 它 们 会 等 和 一 个 “匹配 ?操作 。 


2. 如 果 等 竺 队列 中 的 元 素 和 本 次 操作 是 互补 的 〈 比 如 等 符 操 作 是 





读 ， 而 本 次 操作 是 写 ) ， 那 么 就 插入 一 个 “完成 ”状态 的 市 后 ， 


并 


且 让 他 “匹配 ”到 一 个 等 等 节 点 上 。 接 着 弹出 这 两 个 市 点 ， 并 且 使 


得 对 应 的 两 个 线程 继续 执行 。 





3. 如 果 线 程 发 现 等 待 队 列 的 节点 就 是 “完成 ? 贡 点 ， 那 么 帮助 这 个 布 


点 完成 任务 。 其 流程 和 步骤 2 是 一 致 的 。 


步骤 1 的 实现 如 下 《代码 参考 JDK 7u60) : 


01 SNode h = head; 





02 if (h == null || h.mode == mode) { // WRAY 
03 if (timed && nanos <= 0) { // 不 进行 等 
04 if (h != null && h.isCancelled()) 

05 casHead(h, h.next); // 处 理 取 济 
06 else 

07 return null; 

08 } else if (casHead(h, s = snode(s, e, h, mode))) { 

09 SNode m = awaitFulfill(s, timed, nanos); / 14%, H: 
10 che (m == s) 4 // SERRE 
11 clean(s); 

12 return null; 

13 } 

14 if ((h = head) != null && h.next == s) 

15 casHead(h, s.next); // 帮助 s 的 


16 return (mode == REQUEST) ? m.item : s.item; 


EXAMS, F14{TSNodeRA ESTES FIN ABER SS 
前 线程 、next 节 点 、 匹 配 节点 、 数 据 内 容 等 信息 。 第 2 行 ， 判 断 当 前 等 
竺 队列 为 空 ， 或 者 队列 中 元 又 的 模式 与 本 次 操作 相同 〈 比 如 ， 都 是 读 操 
作 ， 那 么 都 必须 要 等 待 ) 。 第 8 行 ， 生 成 一 个 新 的 节点 并 置 于 队列 头 
部 ， 这 个 节点 就 代表 当前 线程 。 如 果 入 队 成 功 ， 则 执行 第 9 行 
awaitFulfill0) 疯 数 。 该 函数 会 进行 目 旋 等 每 ， 并 最 终 挂 起 当前 线程 。 下 
到 一 个 与 之 对 应 的 操作 产生 ， 将 其 唤醒 。 线 程 被 唤醒 后 (表示 已 经 读 取 
到 数据 或 者 上 自己 产生 的 数据 已 经 被 别 的 线程 该 取 ) ， 在 第 14 一 15 行 答 试 
帮助 对 应 的 线程 完成 两 个 头 部 贡 点 的 出 队 操作 《〈 这 仅仅 是 友情 帮助 ) 。 
并 在 最 后 ， 返 回 读 取 或 者 写 入 的 数据 《第 16 行 ) 。 














步骤 2 的 实现 如 下 : 





01 } else if (!isFulfilling(h.mode)) { // fe BAF Fulfil lis 
02 if (h.isCancelled()) // 如 果 以 前 取消 了 
03 casHead(h, h.next); // 弹出 并 重 试 

04 else if (casHead(h, s=snode(s, e, h, FULFILLING|mode))) { 
05 ror Cery) A // 一 直 循 环 直到 匹配 〈 
06 SNode m = s.next; // m 是 s 的 匹配 者 Cm 
07 if (m == null) { // 已 经 没有 等 待 者 了 
08 casHead(s, null); // 弹出 fulLfil1 节 点 
09 § = null; // 下 一 次 使 用 新 的 节点 
10 break; // 重新 开始 主 循环 


12 SNode mn = m.next; 


13 if (m.tryMatch(s)) { 

14 casHead(s, mn); // 弹出 s 和 m 
15 return (mode == REQUEST) ? m.item : s.item; 
16 } else // match 失败 
17 s.casNext(m, mn); // 帮助 删除 节点 
18 } 

19 } 

20 } 
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再 要 进入 步骤 3。 人 否则 ， 将 视 目 己 为 对 应 的 fulfil 线 程 。 第 4 行 ， 生 成 一 
个 SNode 元 素 ， 设 置 为 fulfill 模 式 并 将 其 压 入 队列 头 部 。 接 着 ， 设 置 
mm《 原 始 的 队列 头 部 ) 为 s 的 匹配 节点 《第 13 行 ) ， 这 个 tryMatch0 操 作 
将 会 激活 一 个 等 待 线程 ， 并 将 m 传 递 给 那个 线程 。 如 果 设 置 成 功 ， 则 表 
示 数 据 投递 完成 ， 将 s 和 症 两 个 节点 弹出 即 可 《第 14 行 ) 。 如 宋 
tryMatchO 失 败 ， 则 表示 已 经 有 其 他 线程 帮 我 完成 了 操作 ， 那 么 简单 得 
删除 m 节 点 即 可 《第 17 行 )， 因 为 这 个 市 点 的 数据 已 经 被 投递 ， 不 需要 
再 次 处 理 ， 然 后 ， 再 次 跳 转 到 第 5 行 的 循环 体 ， 进 行 下 一 个 等 待 线程 的 
匹配 和 数据 投递 ， 直 到 队列 中 没有 等 待 线程 为 止 。 





步骤 3 的 实现 〈 如 果 线 程 在 执行 时 ， 发 现 头 部 元 素 恰 好 是 fulfil 模 
式 ， 它 就 会 帮助 这 个 fulfil 节 点 尽快 被 执行 ) : 


} else { // 帮助 一 个 fulfilles 
SNode m = h.next; // m 是 h 的 match 
if (m == null) // 没有 等 待 者 


casHead(h, null); // 弹出 fulLfil1 节 点 


else { 


SNode mn = m.next; 


if (m.tryMatch(h) ) // 尝试 match 
casHead(h, mn); // 弹出 h 和 m 

else // match 失 败 
h.casNext(m, mn); // 帮助 删除 节点 


上 述 代 码 的 执行 原理 和 步骤 2 是 完全 一 致 的 。 唯 一 的 不 同 是 步骤 3 不 
会 返回 ， 因 为 步 又 3 所 进行 的 工作 古 帮 助 其 他 线程 尽快 投递 它们 的 数 
据 ， 而 自己 并 没有 完成 对 应 的 操作 。 因 此 ， 线 程 进 入 步骤 3 后 ， 再 次 进 
入 大 循环 体 〈 代 码 中 没有 给 出 ) ， 从 步骤 1 开始 重新 判断 条 件 和 投递 数 
Pi o 


从 整个 数据 投递 的 过 程 中 可 以 看 到 ， 在 SynchronousQueue 中 ， 参 与 
工作 的 所 有 线程 不 仅仅 是 竞 争 资源 的 关系 。 更 重要 的 是 ， 它 们 彼此 之 间 
还 会 互相 帮助 。 在 一 个 线程 内 部 ， 可 能 会 帮助 其 他 线程 完成 它们 的 工 
作 。 这 种 模式 可 以 更 大 程度 上 减少 饥饿 的 可 能 ， 提 高 系统 整体 的 并 行 
E. 
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在 学 习 了 无 锁 之 后 ， 让 我 们 重新 回 到 锁 的 世界 吧 ! 在 众多 的 应 用 程 
序 中 ， 使 用 锁 的 情况 一 般 要 多 于 无 锁 。 因 为 对 于 应 用 来 说 ， 如 果 业 务 逻 
辑 很 复 洒 ， 会 极 大 增加 无 锁 的 编程 难度 。 但 如 果 使 用 锁 ， 我 们 就 不 得 不 
对 一 个 新 的 问题 引起 重视 一 一 那 就 是 死 锁 。 





那 什么 是 死 锁 呢 ? 通 俗 的 说 ， 死 锁 就 是 两 个 或 者 多 个 线程 ， 相 互 占 
用 对 方 需要 的 资源 ， 而 都 不 进行 释放 ， 导 致 彼此 之 间 都 相互 等 待 对 方 释 
放 资 源 ， 产 生 了 无 限制 等 待 的 现象 。 死 锁 一 旦 发 生 ， 如 果 没 有 外 力 介 
入 ， 这 种 等 竺 将 永远 存在 ， 从 而 对 程序 产生 严重 的 影 啊 。 





用 来 描述 死 锁 问题 的 一 个 有 名 的 场景 是 “哲学 家 就 餐 ” 问 题 。 哲 学 家 
就 餐 问题 可 以 这 样 表述 ， 假 设 有 五 位 哲学 家 围 坐 在 一 张 圆 形 餐 条 劳 ， 做 
以 下 两 件 事 情 之 一 : 吃饭 ， 或 者 思考 。 吃 东西 的 时 候 ， 他 们 就 停止 思 
考 ， 思 考 的 时 候 也 停止 吃 东 西 。 餐 果 中 间 有 一 大 碗 意大利 面 ， 每 两 个 哲 
学 家 之 间 有 一 只 餐 又 。 因 为 用 一 只 餐 又 很 难 吃 到 意大利 面 ， 所 以 假设 将 
学 家 必须 用 两 只 餐 又 吃 东西 。 他 们 只 能 使 用 目 己 左右 手边 的 那 两 只 餐 
。 哲 学 家 就 餐 问题 有 时 也 用 米饭 和 筷子 而 不 是 意大利 面 和 和 餐 叉 来 描 
， 因 为 很 明显 ， 吃 米饭 必须 用 两 根 饥 子 。 





BF x 


哲学 家 从 来 不 交谈 ， 这 就 很 危险 ， 可 能 产生 死 锁 ， 每 个 哲学 家 都 拿 
独 左 手 的 和 餐 又 ， 永 远 都 在 等 右边 的 餐 又 《或 者 相反 ) 。 如 图 4.3 所 示 ， 
显示 了 这 种 情况 。 
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个 叉子 。A 左 手 拿 着 其 中 一 只 叉子 ，B 也 一 样 。 这 样 他 们 的 右手 等 在 等 
待 对 方 的 叉子 ， 并 且 这 种 等 待 会 一 直 持 续 ， 从 而 导致 程序 永远 无 法 正常 
执行 。 








下 面 让 我 们 用 一 个 简单 的 例子 来 模拟 这 个 过 程 : 


01 public class DeadLock extends Thread { 


02 protected Object tool; 

03 static Object forki = new Object(); 
04 static Object fork2 = new Object(); 
05 

06 public DeadLock(Object obj) { 

07 this.tool = obj; 

08 if (tool == fork1) { 

09 this.setName("#*43%A"); 


10 
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if (tool == fork2) { 


this,setName(" 哲 学 家 B" ) ; 


@Override 
public void run() { 
if (tool == forki) { 
synchronized (fork1) { 
try { 
Thread.sleep(500) ; 
} catch (Exception e) { 
e.printStackTrace(); 
} 
synchronized (fork2) { 
System,out.printLn(" 哲 学 家 A 开 始 吃饭 了 " ) ; 


} 
if (tool == fork2) { 
synchronized (fork2) { 
try { 
Thread.sleep(500) ; 
} catch (Exception e) { 


e.printStackTrace(); 


38 synchronized (fork1) { 


39 System,out.printLn(" 哲 学 家 B 开 始 吃饭 了 " ) ; 
40 } 

41 } 

42 

43 } 

44 } 

45 

46 public static void main(String[] args) throws InterruptedE 
47 DeadLock 哲学 家 A = new DeadLock(fork1); 

48 DeadLock 哲学 家 B = new DeadLock(fork2); 

49 哲学 家 A. start(); 

50 哲学 家 B. start(); 

51 Thread.sleep(1000); 

52 } 

53 } 


EXAMS BD SDAA SEER BRAC HH 
叉子 1， 哲 学 家 B 占 用 叉子 2， 接 着 他 们 就 相互 等 每 ， 都 没有 办 法 同时 获 
得 两 个 又 子 用 和 餐 。 





如 果 在 实际 环境 中 ， 遇 到 了 这 种 情况 ， 通 常 的 表现 就 是 相关 的 进程 
不 再 工作 ， 并 且 CPU 占 用 率 为 0〈 因 为 死 锁 的 线程 不 占用 CPU) ， 不 过 
这 种 表面 现象 只 能 用 来 猜测 问题 。 如 果 想 要 确认 问题 ， 还 需要 使 用 JDK 
提供 的 一 套 专业 工具 。 


首先 ， 我 们 可 以 使 用 ps 命令 得 到 java 进 程 的 进程 ID， 接 着 使 用 
jstack 命 令 得 到 线程 的 线程 堆栈 : 


C:\Users\Administrator>jps 

8404 

944 

3992 DeadLock 

3260 Jps 

// 使 用 jstack 查 看 进程 内 所 有 的 线程 堆栈 

C:\Users\Administrator>jstack 3992 

// 和 省 略 部 分 输出， 只 列 出 当前 与 死 锁 有 关 的 线程 

"哲学 家 B" #9 prio=5 os_prio=0 tid=0x01ccf400 nid=0xb70 waiting for 








java.lang.Thread.State: BLOCKED (on object monitor) 
at geym.conc.ch4.deadlock.DeadLock.run(DeadLock. java: 42) 
- waiting to lock <0x046b3430> (a java.lang.Object) 
- locked <0x046b3438> (a java.lang.Object) 


"哲学 家 A" #8 prio=5 os_prio=0 tid=0x01iccec00 nid=0x1064 waiting fo 
java.lang.Thread.State: BLOCKED (on object monitor) 
at geym.conc.ch4.deadlock.DeadLock.run(DeadLock.java:29) 
- waiting to lock <0x046b3438> (a java.lang.Object) 
- locked <0x046b3430> (a java.lang.Object) 
// 自 动 找到 了 一 个 死 锁 ， 确 认 死 锁 的 存在 


Found one Java-level deadlock: 














"AB": 
waiting to lock monitor 0x15b5bd6c (object 0x046b3430, a java.l 
which is held by "哲学 家 An 

"哲学 家 A'" : 


waiting to lock monitor 0x01c1705c (object 0x046b3438, a java.1l 


which is held by "哲学 ???B" 


Java stack information for the threads listed above: 


// 哲 学 家 A 占用 了 0x046b3430， 等 待 0x0646b3438， 哲 学 家 B 正 好 相反 ， 因 此 产生 死 锁 
"哲学 家 B" 


at geym.conc.ch4.deadlock.DeadLock.run(DeadLock.java:42) 
- waiting to lock <0x046b3430> (a java.lang.Object) 
- locked <0x046b3438> (a java.lang.Object) 

"哲学 家 A'" : 
at geym.conc.ch4.deadlock.DeadLock.run(DeadLock.java:29) 
- waiting to lock <0x046b3438> (a java.lang.Object) 
- locked <0x046b3430> (a java.lang.Object) 


Found 1 deadlock. 


上 面 旺 示 了 jstack 的 部 分 输出 。 可 以 看 到 ， 哲 学 家 A 和 哲学 家 B 两 个 
线程 发 生 了 死 锁 。 并 且 在 最 后 ， 可 以 看 到 两 者 相互 等 待 的 锁 的 ID 。 同 
时 ， 死 锁 的 两 个 线程 均 处 于 BLOCK 状态 。 


如 果 想 避免 死 锁 ， 除 了 使 用 无 锁 的 函数 外 ， 另 外 一 种 有 效 的 做 法 是 
使 用 第 三 章节 介绍 的 重 入 锁 ， 通 过 重 入 锁 的 中 断 或 者 限时 等 待 可 以 有 效 
规避 死 锁 带 来 的 问题 。 大 家 可 以 再 回顾 一 下 相关 内 容 。 
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pose 并行 模式 与 算法 








由 于 并 行程 序 设 计 比 串 行程 序 复 杂 得 多 。 因 此 ， 我 强烈 建议 大 家 可 
以 熟悉 和 了 解 一 些 常 见 的 设计 方法 。 就 好 像 练习 武术 一 样 ， 一 招 一 式 都 
是 要 经 过 学 习 的 。 如 果 自 己 胡 乱 打 一 气 ， 效 果 不 见得 好 。 前 人 会 总 结 一 
些 武术 套路 ， 对 于 初学 者 来 说 ， 不 需要 发 挥 自 己 的 想象 力 ， 只 要 按照 武 
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了 ， 而 不 必 拘 泥 于 套路 。 这 些 武 术 套路 和 招数 ， 对 应 到 软件 开 肥 中 来 ， 
就 是 设计 模式 。 在 这 一 章 中 ， 我 将 重点 同 大 家 介绍 一 些 有 天 并 行 的 设计 
模式 以 及 算法 。 这 些 都 是 前 人 的 经 验 总 结 和 智 意 的 结晶 。 大 家 可 以 在 熟 
知 其 思想 和 原理 的 基础 之 上 ， 再 根据 自己 的 需求 进行 扩展 ， 可 能 会 达到 
更 好 的 效果 。 


























5.1 探讨 单 例 模式 


单 例 模 式 是 设计 模式 中 使 用 最 为 普 裔 的 模式 之 一 。 它 是 一 种 对 象 创 
建 模 式 ， 用 于 产生 一 个 对 象 的 具体 实例 ， 它 可 以 确保 系统 中 一 个 类 只 产 
生 一 个 实例 。 在 Java 中 ， 这 样 的 行为 能 市 来 两 大 好 处 : 


。 对 于 频繁 使 用 的 对 象 ， 可 以 省 略 new 操 作 花 费 的 时 间 ， 这 对 于 那 
些 重量 级 对 象 而 言 ， 是 非常 可 观 的 一 笔 系 统 开销 ; 

。 由 于 new 操 作 的 次 数 减 少 ， 因 而 对 系统 内 存 的 使 用 频率 也 会 降 
低 ， 这 将 减轻 GC 压 力 ， 缩 短 GC 停 顿时 间 。 


严格 来 说 ， 单 例 模 式 与 并 行 没 有 直接 的 关系 。 这 里 我 希望 讨论 这 个 
模式 ， 是 因为 它 实 在 是 太 常 见 了 。 并 且 ， 我 们 不 可 避免 的 ， 会 在 多 线程 
环境 中 使 用 它们 。 并 且 ， 系 统 中 使 用 单 例 的 地 方 可 能 非常 频 蛇 ， 因 此 ， 
我 们 非常 迫切 需要 一 种 高 效 的 单 例 实现 。 














下 面 给 出 了 一 个 单 例 的 实现 ， 这 个 实现 是 非常 简单 的 ， 但 无 疑 是 一 
个 正确 并 且 民 好 的 实现 。 


public class Singleton { 


private Singleton(){ 


System.out.printiln("Singleton is create"); 


private static Singleton instance = new Singleton(); 


1 
2 
3 
4 } 
5 
6 public static Singleton getInstance() { 
7 


return instance; 


使 用 以 上 方式 创建 单 例 有 几 点 必须 特别 注意 。 因 为 我 们 要 保证 系统 
中 不 会 有 人 意外 创建 多 余 的 实例 ， 因 此 ， 我 们 把 Singleton 的 构造 函数 设 
置 为 private。 这 点 非常 重要 ， 这 就 警告 所 有 的 开发 人 员 ， 不 能 随便 创建 
这 个 类 的 实例 ， 从 而 有 效 避 免 该 类 被 错误 的 创建 。 


第 二 点 ，instance 对 象 必须 是 private 并 且 static 的 。 如 果 不 是 private， 
那么 instance 的 安全 性 无 法 得 到 保证 。 一 个 小 小 的 意外 束 可 能 使 得 
instance 变 成 null。 其 次 ， 因 为 工厂 方法 getInstance() 必 须 是 static 的 ， 因 此 
对 应 的 instance 也 必须 是 static。 


这 个 单 例 的 性 能 是 非常 好 的 ， 因 为 getInstance() 方 法 只 是 简单 地 返 
回 instance， 并 没有 任何 锁 操 作 ， 因 此 它 在 并 行程 序 中 ， 会 有 民 好 的 表 
现 。 





但 是 这 种 方式 有 一 点 明显 不 足 ， 束 是 Singleton 构 造 函 数 ， 或 者 说 
Singleton 实 例 在 什么 时 候 创 建 是 不 受 控制 的 。 对 于 静态 成 员 instance， 它 
会 在 类 第 一 次 初始 化 的 时 候 被 创建 。 这 个 时 刻 并 不 一 定 是 getInstance() 
方法 第 一 次 被 调用 的 时 候 。 


比如 ， 如 果 你 的 单 例 像 是 这 样 的 : 


public class Singleton { 
public static int STATUS=1; 
private Singleton(){ 


System.out.printin("Singleton is create"); 


private static Singleton instance = new Singleton(); 
public static Singleton getInstance() { 


return instance; 


注意 ， 这 个 单 例 还 包含 一 个 表示 状态 的 静态 成 员 STATUS。 此 时 ， 
在 相同 任何 地 方 引 用 这 个 STATUS 都 会 导致 mstance 实 例 被 创建 〈 任 何 对 
Singleton 方 法 或 者 字段 的 引用 ， 都 会 导致 类 初始 化 ， 并 创建 instance 实 
例 ， 但 是 类 初始 化 只 有 一 次 ， 因 此 instance 实 例 永 远 只 会 被 创建 一 
次 ) 。 比 如 : 


System.out.printin(Singleton.STATUS); 
上 述 println 会 打印 出 : 


Singleton is create 


1 


可 以 看 到 ， 即 使 系统 没有 要 求 创建 单 例 ，new Singleton0) 也 会 被 调 
用 。 





如 果 大 家 觉得 这 个 小 小 的 不 足 并 不 重要 ， 我 认为 这 种 单 例 模 式 是 一 
种 不 错 的 选择 。 它 容易 实现 ， 代 码 易 读 而 且 性 能 优越 。 


但 如 果 你 想 精 确 控制 instance 的 创建 时 间 ， 那 么 这 种 方式 束 不 太 友 
善 了 。 我 们 需要 寻找 一 种 新 的 方法 ， 一 种 支持 延迟 加 载 的 策略 ， 它 只 会 
在 instance 被 第 一 次 使 用 时 ， 创 建 对 象 。 具 体 实 现 如 下 : 


01 public class LazySingleton { 


02 private LazySingleton() { 


03 System.out.printin("LazySingleton is create"); 
04 } 
05 private static LazySingleton instance = null; 
06 public static synchronized LazySingleton getInstance() { 
07 if (instance == null) 
08 instance = new LazySingleton(); 
09 return instance; 
10 } 
11 } 
这 个 LazySingleton 的 核心 思想 如 下 : 最 初 ， 我 们 并 不 需要 实例 化 


instance， 而 当 getInstance() 方 法 被 第 一 次 调用 时 ， 创 建 单 例 对 象 。 为 了 
防止 对 象 被 多 次 创建 ， 我 们 不 得 不 使 用 synchronized 进 行 方法 同步 。 这 
种 实现 的 好 处 是 ， 充 分 利用 了 延迟 加 载 ， 只 在 真正 需要 时 创建 对 象 。 但 
坏处 也 很 明显 ， 并 发 环境 下 加 锁 ， 竞 争 激 烈 的 场合 对 性 能 可 能 产生 一 定 
的 影响 。 但 总 体 上 ， 这 是 一 个 非常 易于 实现 和 理解 的 方法 。 





此 外 ， 还 有 一 种 被 称 为 双重 检查 模式 的 方法 可 以 用 于 创建 单 例 。 但 
我 并 不 打算 在 这 里 介绍 它 ， 因 为 这 是 一 种 非常 丑陋 、 复 杂 的 方法 ， 甚 至 
在 低 版 本 的 JDK 中 都 不 能 保证 正确 性 。 因 此 ， 绝 不 推荐 大 家 使 用 。 如 果 
大 家 阅读 到 相关 文档 ， 我 也 强烈 建议 大 家 不 要 在 这 种 方法 上 花费 太 多 时 
间 。 








在 上 述 介绍 的 两 种 单 例 实现 中 ， 可 以 说 是 各 有 千秋 。 有 没有 一 各 方 
法 可 以 结合 二 者 之 优势 呢 ? 答案 是 肯定 的 : 


01 public class StaticSingleton { 


02 private StaticSingleton(){ 


03 System.out.println("StaticSingleton is create"); 

04 } 

05 private static class SingletonHolder { 

06 private static StaticSingleton instance = new StaticSi 
07 } 

08 public static StaticSingleton getInstance() { 

09 return SingletonHolder.instance; 

10 } 

11 } 





上 述 代码 实现 了 一 个 单 例 ， 并 且 同 时 拥有 前 两 种 方式 的 有 点 。 首 先 
getInstance() 方 法 中 没有 锁 ， 这 使 得 在 高 并 发 环境 下 性 能 优越 。 其 次 ， 
只 有 在 getInstance() 方 法 被 第 一 次 调用 时 ，StaticSingleton 的 实例 才 会 被 
创建 。 因 为 这 种 方法 巧妙 地 使 用 了 内 部 类 和 类 的 初始 化 方式 。 内 部 类 
SingletonHolder 被 申明 为 private， 这 使 得 我 们 不 可 能 在 外 部 访问 并 初始 
化 它 。 而 我 们 只 可 能 在 getInstance() 内 部 对 SingletonHolder 类 进行 初始 
化 ， 利 用 虚拟 机 的 类 初始 化 机 制 创建 单 例 。 








5.2 PETA 


在 并 行 软件 开发 过 程 中 ， 同 步 操 作 似乎 是 必 不 可 少 的 。 当 多 线程 对 
同一 个 对 象 进行 读 写 操作 时 ， 为 了 保证 对 象 数据 的 一 致 性 和 正确 性 ， 有 
必要 对 对 象 进行 同步 。 而 同步 操作 对 系统 性 能 是 有 相当 的 损耗 。 为 了 能 
尽 可 能 地 去 除 这 些 同步 操作 ， 提 高 并 行程 序 性 能 ， 可 以 使 用 一 种 不 可 改 
变 的 对 象 ， 依 徘 对 象 的 不 变性 ， 可 以 确保 其 在 没有 同步 操作 的 多 线程 环 
境 中 依然 始终 保持 内 部 状态 的 一 致 性 和 正确 性 。 这 就 是 不 变 模 式 。 








不 变 模 式 天 生 就 是 多 线程 友好 的 ， 它 的 核心 思想 是 ， 一 个 对 象 一 旦 
被 创建 ， 则 它 的 内 部 状态 将 永远 不 会 发 生 改 变 。 所 以 ， 疫 有 一 个 线程 可 
以 修改 其 彤 部 状态 和 数据 ， 同 时 其 内 部 状态 也 绝 不 会 自行 发 生 改 变 。 基 
于 这 些 特性 ， 对 不 变 对 象 的 多 线程 操作 不 需要 进行 同步 控制 。 











同时 还 需要 注意 ， 不 变 模式 和 只 读 属 性 是 有 一 定 的 区 别 的 。 不 变 模 
式 是 比 只 读 属性 具有 更 强 的 一 致 性 和 不 变性 。 对 只 读 属性 的 对 象 而 言 ， 
对 象 本 身 不 能 和 被 其 他 线程 修改 ， 但 是 对 象 的 目 身 状态 却 可 能 目 行 修改 。 





比如 ， 一 个 对 象 的 存活 时 间 (对 象 创建 时 间 和 当前 时 间 的 时 间 差 ) 
古 只 读 的 ， 因 为 任何 一 个 第 三 方 线程 都 不 能 修改 这 个 属性 ， 但 是 这 是 一 
个 可 变 的 属性 ， 因 为 随 着 时 间 的 推移 ， 存 活 时 间 时 刻 都 在 发 生变 化 。 而 
不 变 模 式 则 要 求 ， 无 论 出 于 什么 原因 ， 对 象 目 创建 后 ， 其 内 部 状态 和 数 
据 保 持 绝对 的 稳定 。 








因此 ， 不 变 模式 的 主要 使 用 场景 需要 满足 以 下 2 个 条 件 : 


。 当 对 象 创 建 后 ， 其 内 部 状态 和 数据 不 再 发 生 任何 变化 。 


。 对 象 需要 被 共享 ， 被 多 线程 频繁 访问 。 


在 Java 语 言 中 ， 不 变 模式 的 实现 很 简单 。 为 确保 对 象 被 创建 后 ， 不 
发 生 任 何 改变 ， 并 保证 不 变 模式 正常 工作 ， 只 需要 注意 以 下 4 扩 : 








。 去 除 setter 方 法 以 及 所 有 修改 自 喘 属性 的 方法 。 

。 将 所 有 属性 设置 为 私有 ， 并 用 final 标 记 ， 确 保 其 不 可 修改 。 
。 确保 没有 子 类 可 以 重 载 修改 它 的 行为 。 

© 有 一 个 可 以 创建 完整 对 象 的 构造 函数 。 





以 下 代码 实现 了 一 个 不 变 的 产品 对 象 ， 它 拥有 序列 号 、 名 称 和 价格 
三 个 属性 。 


public final class Product { // 确 保 无 子 : 
private final String no; // 私 有 属性 ， 





private final String name; //final 保 ii 


private final double price; 


public Product(String no, String name, double price) { //%) 
super(); 





// 因 为 创建 ; 
this.no = no; 


this.name = name; 


this.price = price; 


public String getNo() { 


return no; 


public String getName() { 
return name; 

J 

public double getPrice() { 


return price; 





在 不 变 模式 的 实现 中 ，final 关 键 字 起 到 了 重要 的 作用 。 对 属性 的 
final 定 义 确保 所 有 数据 只 能 在 对 象 被 构造 时 赋值 1 次 。 之 后 ， 束 永远 不 
再 及 生 改 变 。 而 对 class 的 final 确 保 了 类 不 会 有 子 类 。 根 据 里 氏 代 换 原 
则 ， 子 类 可 以 完全 的 符 代 父 类 。 如 宁 父 类 是 不 变 的 ， 那 么 子 类 也 必须 是 
不 变 的 ， 但 实际 上 我 们 并 无 法 约束 这 点 ， 为 了 防止 子 类 做 出 一 些 意外 的 
行为 ， 这 里 就 干脆 把 子 类 都 茶 用 了 。 


在 JDK 中 ， 不 变 模式 的 应 用 非常 广泛 。 其 中 ， 最 为 典型 的 就 是 
java.lang.String 类 。 此 外 ， 所 有 的 元 数据 类 包装 类 ， 都 是 使 用 不 变 模式 
实现 的 。 主 要 的 不 变 模式 类 型 如 下 : 


java.lang.String 


java.lang.Boolean 


java.lang.Byte 


java.lang.Character 


java.lang.Double 


java.lang.Float 


java.lang.Integer 


java.lang. Long 


java.lang.Short 


由 于 基本 数据 类 型 和 String 类 型 在 实际 的 软件 开发 中 应 用 极其 广 
泛 ， 使 用 不 变 模式 后 ， 所 有 实例 的 方法 均 不 需要 进行 同步 操作 ， 保 证 了 
它们 在 多 线程 环境 下 的 性 能 。 








注意 : 不 变 模 式 通过 回避 问题 而 不 是 解决 问题 的 态度 来 处 理 多 线程 
并 发 访问 控制 。 不 变 对 象 是 不 需要 进行 同步 操作 的 。 由 于 并 发 同步 
会 对 性 能 产生 不 良 的 影响 ， 因 此 ， 在 需求 允许 的 情况 下 ， 不 变 模 式 
可 以 提高 系统 的 并 发 性 能 和 并 发 量 。 


5.3 生产 着- 消费 者 模式 


生产 者 -消费 者 模式 是 一 个 经 典 的 多 线程 设计 模式 ， 它 为 多 线程 间 
的 协作 提供 了 良好 的 解决 方案 。 在 生产 者 -消费 者 模式 中 ， 通 常 有 两 类 
线程 ， 即 符 干 个 生产 者 线程 和 奉 干 个 消费 者 线程 。 生 产 者 线程 负责 提交 
用 户 请 求 ， 消 费 者 线程 则 负责 具体 处 理 生产 者 提交 的 任务 。 生 产 者 和 消 
费 者 之 间 则 通过 共享 内 存 缓冲 区 进行 通信 。 














如 图 5.1 所 示 ， 展 示 了 生产 者 -消费 者 模式 的 基本 结构 。 三 个 生产 者 
线程 将 任务 提交 到 共享 内 存 缓冲 区 ， 消 费 者 线程 并 不 直接 与 生产 者 线程 
通信 ， 而 在 共享 内 存 绥 冲 区 中 获取 任务 ， 并 进行 处 理 。 
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图 5.1 生产 者 -消费 者 模式 架构 图 
JER: 生产 者 -消费 者 模式 中 的 内 存 缓存 区 的 主要 功能 是 数据 在 多 


线程 间 的 共享 ， 此 外 ， 通 过 该 缓冲 区 ， 可 以 缓解 生产 者 和 消费 者 间 
的 性 能 差 。 












生产 者 -消费 者 模 陈 的 核心 组 件 是 共 孚 内 存 缓存 区 ， 它 作为 生产 者 
和 消费 者 间 的 通信 桥 染 ， 避 免 了 生产 者 和 消费 者 的 直接 通信 ， 从 而 将 生 





产 者 和 消费 者 进行 解 奈 。 生 产 者 不 需要 知 着 消费 者 的 存在 ， 消 费 者 也 不 
需要 知道 生产 者 的 存在 。 





同时 ， 由 于 内 存 缓冲 区 的 存在 ， 多 许 生产 者 和 消费 者 在 执行 速度 上 
存在 时 间 差 ， 无 论 是 生产 者 在 某 一 局 部 时 间 内 速度 高 于 消费 者 ， 还 是 消 
费 者 在 局 部 时 间 内 高 于 生产 者 ， 都 可 以 通过 共享 和 内存 缓 冲 区 得 到 缓解 ， 
确保 系统 正常 运行 。 











生产 者 -消费 者 模式 的 主要 角色 如 表 5.1 所 示 。 


表 5.1 生产 者 -消费 者 模式 主要 角色 








































































































角色 作用 

生产 者 ] 于 提交 用 户 请 求 ， 提 取 用 户 任务 ， 并 装 入 内 存 缓冲 区 
消费 者 在 内 存 缓冲 区 中 提取 并 处 理 任务 

内 存 缓冲 区 缓存 生产 者 提交 的 任务 或 数据 ， 供 消费 者 使 用 

任务 生成 者 向 内 存 缓冲 区 提交 的 数据 结构 

Main 使 用 生产 者 和 消费 者 的 客户 端 























图 5.2 显 示 了 生产 者 -消费 者 模式 一 种 实现 的 具体 结构 。 
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图 5.2 生产 者 -消费 者 实现 类 图 





其 中 ，BlockigQueue 充 当 了 共享 内 存 绥 冲 区 ， 用 于 维护 任务 或 数据 
队列 “PCData 对 象 》。 我 强烈 建议 大 家 先 回顾 一 下 第 3 章 有 关 
BlockingQueue 的 相关 知识 ， 对 于 理解 整个 生产 者 和 消费 者 结构 有 重要 
的 帮助 。PCData 对 象 表示 一 个 生产 任务 ， 或 者 相关 任务 的 数据 。 生 产 者 
对 象 和 消费 者 对 象 均 引用 同一 个 BlockigQueue 实 例 。 生 产 者 负责 创建 
PCData 对 象 ， 并 将 它 加 入 BlockigQueue 中 ， 消 费 者 则 从 BlockigQueue 队 
列 中 获取 PCData。 











基于 图 5.2 所 示 结 构 ， 实 现 一 个 基于 生产 者 -消费 者 模式 的 求 整数 平 
方 的 并 行程 序 。 


首先 ， 生 产 者 线程 的 实现 如 下 ， 它 构建 PCData 对 象 ， 并 放 入 
BlockingQueue 队 列 中 。 


public class Producer implements Runnable { 
private volatile boolean isRunning = true; 
private BlockingQueue<PCData> queue; / 
private static AtomicInteger count = new AtomicInteger(); 


private static final int SLEEPTIME = 1000; 
public Producer(BlockingQueue<PCData> queue) { 


this.queue = queue; 


public void run() { 


PCData data = null; 


Random r = new Random(); 


System.out.printlin("start producer id="+Thread.currentThr 
try { 
while (isRunning) { 
Thread.sleep(r.nextInt(SLEEPTIME)); 
data = new PCData(count.incrementAndGet()); 
System.out.println(data+" is put into queue"); 
if (!queue.offer(data, 2, TimeUnit.SECONDS)) { 


System.err.println("failed to put data: " + dé 


} 
} catch (InterruptedException e) { 
e.printStackTrace(); 


Thread.currentThread().interrupt(); 


J 
public void stop() { 


isRunning = false; 


对 应 的 消费 者 的 实现 如 下 。 它 从 BlockingQueue 队 列 中 取出 PCData 
对 象 ， 并 进行 相应 的 计算 。 


public class Consumer implements Runnable { 


private BlockingQueue<PCData> queue; //2 


private static final int SLEEPTIME = 1000; 


public Consumer (BlockingQueue<PCData> queue) { 


this.queue = queue; 


public void run() { 
System.out.printin("start Consumer id=" 


+ Thread.currentThread().getId()); 


Random r = new Random(); // 随 机 等 
try { 
while(true) { 
PCData data = queue.take(); // 提 取 任 


if (null != data) { 
int re = data.getData() * data.getData(); 
System.out.println(MessageFormat.format("{0}* 
data.getData(), data.getData(), re)); 


Thread.sleep(r.nextInt(SLEEPTIME) ); 


} 
} catch (InterruptedException e) { 


e.printStackTrace(); 


Thread.currentThread().interrupt(); 


PCData 作 为 生产 者 和 消费 者 之 间 的 共享 数据 模型 ， 定 义 如 下 : 


public final class PCData { // 任 务 相关 
private final int intData; // 数 据 
public PCData(int d){ 
intData=d; 
b 
public PCData(String d){ 
intData=Integer.value0f(d); 
} 
public int getData(){ 
return intData; 
} 
@Override 
public String toString(){ 


return "data:"+intData; 


在 主 函 数 中 ， 创 建 三 个 生产 者 和 三 个 消费 者 ， 并 让 它们 协作 运行 。 
在 主 函 数 的 实现 中 ， 定 义 LinkedBlockingQueue 作 为 BlockingQueue 的 实 
现 类 O 


public class Main { 
public static void main(String[] args) throws InterruptedExce 
// 建 立 缓冲 区 


BlockingQueue<PCData> queue = new LinkedBlockingQueue<P 





Producer producer1 = new Producer (queue); 
Producer producer2 = new Producer (queue); 
Producer producer3 = new Producer (queue); 
Consumer consumer1 = new Consumer (queue); 
Consumer consumer2 = new Consumer (queue); 
Consumer consumer3 = new Consumer (queue); 
ExecutorService service = Executors.newCachedThreadPool( ) 
service.execute(producer1); 
service.execute(producer2); 
service.execute(producer3); 
service.execute(consumer1) ; 
service.execute(consumer2); 
service.execute(consumer3) ; 
Thread.sleep(10 * 1000); 
producer1.stop(); 

producer2.stop(); 

producer3.stop(); 

Thread.sleep( 3000) ; 


service.shutdown(); 


注意 : 生产 者 -消费 者 模式 很 好 地 对 生产 者 线程 和 消费 者 线程 进行 
解 烛 ， 优 化 了 系统 整体 结构 。 同 时 ， 由 于 缓冲 区 的 作用 ， 人 允许 生产 
者 线程 和 消费 者 线程 存在 执行 上 的 性 能 差异 ， 从 一 定 程度 上 缓解 了 
性 能 瓶颈 对 系统 性 能 的 影响 。 


54 高 性 能 的 生产 者 -消费 者 : 无 
锁 的 实现 


BlockigQueue 用 于 实现 生产 者 和 消费 者 一 个 不 错 的 选择 。 它 可 以 很 
自然 地 实现 作为 生产 者 和 消费 者 的 内 存 缓冲 区 。 但 是 BlockigQueue 并 不 
是 一 个 高 性 能 的 实现 ， 它 完全 使 用 锁 和 阻塞 等 待 来 实现 线程 则 的 同步 。 
在 高 并 发 场合 ， 它 的 性 能 并 不 是 特别 的 优越 。 惑 像 之 前 我 已 经 提 过 的 : 
ConcurrentLinkedQueue 是 一 个 高 性 能 的 队列 ， 但 是 BlockingQueue 只 是 


为 了 方便 数据 共 至 。 





而 ConcurrentLinkedQueue 的 秘诀 就 在 于 大 量 使 用 了 无 锁 的 CAS 操 
作 。 同 理 ， 如 果 我 们 使 用 CAS 来 实现 生产 者 -消费 者 模式 ， 也 同样 可 以 
获得 可 观 的 性 能 提升 。 不 过 正如 大 家 所 见 ， 使 用 CAS 进 行 编程 是 非常 困 
难 的 ， 但 有 一 个 好 消 恩 是 ， 目 前 有 一 个 现成 的 Disruptor 框 架 ， 它 已 经 帮 
助 我 们 实现 了 这 一 个 功能 。 











5.4.1 EMEF: Disruptor 


Disruptor 框 染 是 由 LMAX 公 司 开 发 的 一 款 高 效 的 无 锁 内 存 队 列 。 它 
使 用 无 锁 的 方式 实现 了 一 个 环形 队列 ， 非 常 适 合 于 实现 生产 者 和 消费 者 
模式 ， 比 如 事件 和 消息 的 发 布 。 在 Disruptor 中 ， 别 出 心 裁 地 使 用 了 环形 
KAS) CRingBuffer) 来 代 蔡 普通 线性 队列 ， 这 个 环形 队列 内 部 实现 为 一 
个 普通 的 数组 。 对 于 一 般 的 队列 ， 势 必要 提供 队列 同步 head 和 尾部 tail 两 
个 指针 ， 用 于 出 队 和 入 队 ， 这 样 无 疑 就 增加 了 线程 协作 的 复杂 度 。 但 如 


果 队 列 是 环形 的 ， 则 只 需要 对 外 提供 一 个 当前 位 置 cursor， 利 用 这 个 指 
针 既 可 以 进入 入 队 也 可 以 进行 出 队 操 作 。 由 于 环形 队列 的 缘故 ， 队 列 的 
总 大 小 必须 事先 指定 ， 不 能 动态 扩展 。 为 了 能 够 快速 从 一 个 序列 
(sequence) 对 应 到 数组 的 实际 位 置 〈 每 次 有 元 素 入 队 ， 序 列 束 加 1) ， 
Disruptor 要 求 我 们 必须 将 数组 的 大 小 设置 为 2 的 整数 次 方 。 这 样 通过 
sequence &(queueSize-1) 束 能 并 即 定 位 到 实际 的 元 素 位 置 index。 这 个 要 
比 取 余 (%) 操作 快 得 多 。 


如 果 大 家 不 理解 上 面 的 sequence ”&(queueSize-1)， 我 在 这 里 再 简单 
说 明 一 下 。 如 果 queueSize 是 2 的 整数 次 时 ， 则 这 个 数字 的 二 进 制 表示 必 
然 是 10、100、1000、10000 等 形式 。 因 此 ，queueSize-1 的 二 进 制 则 是 一 
个 全 1 的 数字 。 因 此 它 可 以 将 sequence 限 定 在 queueSize-1 范 围 内 ， 并 且 不 
会 有 任何 一 位 是 浪费 的 。 





如 图 5.3 所 示 ， 显 示 了 RingBuffer 的 结构 。 生 产 者 问 绥 冲 区 中 写 入 数 
据 ， 而 消费 者 从 中 读 取 数据 。 生 产 者 写 入 数据 时 ， 使 用 CAS 操 作 ， 消 费 
者 读 取 数 据 时 ， 为 了 防止 多 个 消费 者 处 理 同一 个 数据 ， 也 使 用 CAS 操 作 
进行 数据 保护 。 
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图 5.3 Disruptor 的 RingBuffer 结 构 


这 种 固定 大 小 的 环形 队列 的 另外 一 个 好 处 就 是 可 以 做 到 完全 的 内 存 
复 用 。 在 系统 的 运行 过 程 中 ， 不 会 有 新 的 空间 需要 分 配 或 者 老 的 空间 需 
要 回收 。 因 此 ， 可 以 大 大 减少 系统 分 配 空间 以 及 回收 空间 的 额外 开销 。 





5.4.2 ”用 Disruptor 实 现 生 产 者 -消费 者 
RW 
现在 我 们 已 经 基本 了 解 了 Disruptor 的 基本 实现 。 在 本 节 ， 我 们 将 展 


示 一 下 Disruptor 的 基本 使 用 和 API， 这 里 ， 我 们 使 用 的 版 本 是 disruptor- 
3.3.2， 不 同 版 本 的 disruptor 可 能 会 有 细微 的 差别 ， 也 请 大 家 留意 。 





这 里 ， 我 们 的 生产 者 不 断 产生 整数 ， 消 费 者 读 取 生产 者 的 数据 ， 并 
计算 其 平方 。 


首先 ， 我 们 还 是 需要 一 个 代表 数据 的 PCData: 


public class PCData 
{ 
private long value; 
public void set(long value) 
{ 
this.value = value; 
} 
public long get(){ 


return value; 





消费 者 实现 为 WorkHandler 接 口 ， 它 来 自 Disruptor 框 架 : 


public class Consumer implements WorkHandler<PCData> { 
@Override 
public void onEvent(PCData event) throws Exception { 
System.out.printin(Thread.currentThread().getId() + ":Eve 


+ event.get() * event.get() + "--"); 


消费 者 的 作用 是 读 取 数 据 进 行 处 理 。 这 里 ， 数 据 的 读 取 己 经 由 
Disruptor 进 行 封 狼 ，onEvent() 方 法 为 框架 的 回调 方法 。 因 此 ， 这 里 只 需 
要 简单 地 进行 数据 处 理 即 可 。 


还 需要 一 个 产生 PCData 的 工厂 类 。 它 会 在 Disruptor 系 统 初 始 化 时 ， 
构造 所 有 的 缓冲 区 中 的 对 象 实 例 (之 前 说 过 Disruptor 会 预先 分 配 空 
间 ) : 


public class PCDataFactory implements EventFactory<PCData> 


{ 


public PCData newInstance( ) 


f 


return new PCData(); 


接着 ， 让 我 们 来 看 一 下 生产 者 ， 它 比 前 面 几 个 类 稍微 复杂 一 点 : 


01 public class Producer 


02 { 


03 private final RingBuffer<PCData> ringBuffer; 

04 

05 public Producer(RingBuffer<PCData> ringBuffer ) 

06 { 

07 this.ringBuffer = ringBuffer; 

08 } 

09 

10 public void pushData(ByteBuffer bb) 

11 { 

12 long sequence = ringBuffer.next(); // Grab the next s 
13 try 

14 { 

15 PCData event = ringBuffer.get(sequence); // Get th 
16 

17 event.set(bb.getLong(0)); // Fill with data 
18 } 

19 finally 

20 { 

21 ringBuffer.publish( sequence); 

22 } 

23 } 

24 } 


生产 者 需要 一 个 RingBuffer 的 引用 ， 也 束 是 环形 缓冲 区 。 它 有 一 个 
重要 的 方法 pushData0 将 产生 的 数据 推 入 缓冲 区 。 方 法 pushData0 接 收 一 
个 ByteBuffer 对 象 。 在 ByteBuffer 中 可 以 用 来 包装 任何 数据 类 型 。 这 里 用 


来 存储 long 整 数 ，pushData0 的 功能 就 是 将 传 入 的 ByteBuffer 中 的 数据 提 
取出 来 ， 并 装载 到 环形 缓冲 区 中 。 


上 述 第 12 行 代码 ， 通 过 next() 方 法 得 到 下 一 个 可 用 的 序列 号 。 通 过 
序列 号 ， 取 得 下 一 个 空 闪 可 用 的 PCData， 并 且 将 PCData 的 数据 设 为 期 
望 值 ， 这 个 值 最 终 会 传递 给 消费 者 。 最 后 ， 在 第 21 行 ， 进 行 数据 发 布 。 
只 有 发 布 后 的 数据 才 会 真正 被 消费 者 看 见 。 


至 此 ， 我 们 的 生产 者 、 消 费 者 和 数据 都 已 经 准备 就 绪 。 只 差 一 个 统 
筹 规划 的 主 函数 将 所 有 的 内 容 整 合 起 来 : 


01 public static void main(String[] args) throws Exception 


02 { 

03 Executor executor = Executors.newCachedThreadPool(); 

04 PCDataFactory factory = new PCDataFactory(); 

05 // Specify the size of the ring buffer, must be power of 2 
06 int bufferSize = 1024; 

07 Disruptor <PCData> disruptor = new Disruptor<PCData> (faci 
08 bufferSize, 

09 executor, 

10 ProducerType.MULTI, 

11 new BlockingWaitStrategy() 

12 ); 

13 disruptor .handleEventswithworkerPool( 

14 new Consumer (), 

15 new Consumer (), 

16 new Consumer (), 


17 new Consumer ()); 


18 disruptor.start(); 


19 

20 RingBuffer<PCData> ringBuffer = disruptor.getRingBuffer( ) 
21 Producer producer = new Producer(ringBuffer ); 
22 ByteBuffer bb = ByteBuffer.allocate(8); 

23 for (long 1 = 0; true; 1++) 

24 { 

25 bb.putLong(0, 1); 

26 producer .pushData(bb); 

27 Thread.sleep(100); 

28 System.out.println("add data "+1); 

29 } 

30 } 


上 述 代码 第 6 行 ， 设 置 缓 冲 区 大 小 为 1024。 显 然 是 2 的 整数 次 贤 一 一 
一 个 合理 的 大 小 。 第 7 一 12 创 建 了 disruptor 对 象 。 它 封装 了 整个 disruptor 
库 的 使 用 ， 提 供 了 一 些 便捷 的 API。 第 13 一 17 行 ， 设 置 了 用 于 处 理 数 据 
的 消费 者 。 这 里 设置 了 4 个 消费 者 实例 ， 系 统 会 为 将 每 一 个 消费 者 实例 
映射 到 一 个 线程 中 ， 也 就 是 这 里 提供 了 4 个 消费 者 线程 。 第 18 行 ， 局 动 
并 初始 化 disruptor 系 统 。 在 第 23 一 29 行 中 ， 由 一 个 生产 者 不 断 地 癌 绥 冲 
区 中 存 入 数据 。 


系统 执行 后 ， 你 就 可 以 得 到 类 似 以 下 的 输出 : 


8:Event: --0-- 
add data 0 
11:Event: --1-- 


add data 1 


10:Event: --4-- 
add data 2 
Q:Event: --9-- 


add data 3 


生产 者 和 消费 者 正常 工作 。 根 据 Disruptor 的 官方 报告 ，Disruptor 的 
性 能 要 比 BlockingQueue 人 至 少 高 一 个 数量 级 以 上 。 如 此 族人 的 性 能 ， 当 
然 值 得 我 们 去 尝试 ! 


5.4.3 fer oa WMA DV AY TA): 选择 
er HY SHS 


当 有 新 数据 在 Disruptor 的 环形 缓冲 区 中 产生 时 ， 消 费 者 如 何 知道 这 
些 新 产生 的 数据 呢 ? 或 者 说 ， 消 费 者 如 何 监控 缓冲 区 中 的 信息 呢 ? 为 
此 ，Disruptor 提 供 了 几 种 策略 ， 这 些 策略 由 WaitStrategy 接 口 进 行 封装 ， 
主要 有 以 下 几 种 实现 。 


e BlockingWaitStrategy: 这 是 默认 的 策略 。 使 用 
BlockingWaitStrategy 和 使 用 BlockingQueue 是 非常 类 似 的 ， 它 们 
都 使 用 锁 和 条 件 〈Condition ) 进行 数据 的 监控 和 线程 的 唤醒 。 
为 涉及 到 线程 的 切换 ，BlockingWaitStrategy 策 略 是 最 节省 CPU， 
但 是 在 高 并 发 下 性 能 表现 最 糟糕 的 一 种 等 竺 策略 。 
SleepingWaitStrategy: 这 个 策略 也 是 对 CPU 使 用 率 非 常 保 守 的 。 
它 会 在 循环 中 不 断 等 待 数据 。 它 会 先进 行 自 旋 等 待 ， 如 果 不 成 
功 ， 则 使 用 Thread.yield0 让 出 CPU， 并 最 终 使 用 
LockSupport.parkNanos(1) 进 行 线程 休眠 ， 以 确保 不 占用 太 多 的 

















CPU 数据 。 因 此 ， 这 个 策略 对 于 数据 处 理 可 能 产生 比较 高 的 平均 
延 时 。 它 比较 适合 于 对 延 时 要 求 不 是 特别 高 的 场合 ， 好 处 是 它 对 
生产 者 线程 的 影响 最 小 。 典 型 的 应 用 场景 是 异步 日 志 。 
YieldingWaitStrategy: 这 个 策略 用 于 低 延 时 的 场合 。 消 费 者 线程 
会 不 断 循环 监控 绥 冲 区 变化 ， 在 循环 内 部 ， 它 会 使 用 
Thread.yield0 让 出 CPU 给 别 的 线程 执行 时 间 。 如 果 你 需要 一 个 高 
性 能 的 系统 ， 并 且 对 延 时 有 较为 严格 的 要 求 ， 则 可 以 考虑 这 种 策 
略 。 使 用 这 种 策略 时 ， 相 当 于 你 的 消费 者 线程 变 身 成 为 了 一 个 内 
部 执行 了 Thread.yield0 的 死 循 环 。 因 此 ， 你 最 好 有 多 于 消费 者 线 
程 数 量 的 逻辑 CPU 数 量 ( 这 里 的 逻辑 CPU， 我 指 的 是 “双核 四 线 
程 ”* 中 的 那个 四 线程 ， 否 则 ， 整 个 应 用 程序 恐怕 都 会 受到 影响 。 
BusySpinWaitStrategy: 这 个 是 最 疯狂 的 等 待 集 略 了 。 它 就 是 一 个 
死 循环 ! 消费 者 线程 会 尽 最 大 努力 疯狂 监控 缓冲 区 的 变化 。 
此 ， 它 会 吃 挥 所 有 的 CPU 资 源 。 你 只 有 在 对 延迟 非常 苛刻 的 场合 
可 以 考虑 使 用 它 ( 或 者 说 ， 你 的 系统 真 的 非常 繁忙 ，。 因 为 在 这 
里 你 等 同 开启 了 一 个 死 循 环 监控 ， 所 以 ， 你 的 物理 CPU 数量 必须 
要 大 于 消费 者 线程 数 。 注 意 ， 我 这 里 说 的 是 物理 CPU， 如 果 你 在 
一 个 物理 核 上 使 用 超 线程 技术 模拟 两 个 还 辑 核 ， 另 外 一 个 逻辑 核 
显然 会 受到 这 种 超 密集 计算 的 影响 而 不 能 正常 工作 。 


























在 上 面 的 例子 中 ， 使 用 的 是 BlockingWaitStrategy (281147) 。 读 者 
可 以 将 换 这 个 实现 ， 体 验 一 下 不 同等 待 策略 的 效果 。 


5.4.4 CPU Cache 的 优化 : 解决 伪 共 
享 问 题 


除了 使 用 CAS 和 提供 了 各 种 不 同 的 等 待 集 略 来 提高 系统 的 否 吐 量 
外 。Disruptor 大 有 将 优化 进行 到 底 的 气势 ， 它 甚至 尝试 解决 CPU 绥 存 的 


伪 共 享 问题 。 


什么 是 伪 共 享 问题 呢 ? 我 们 知道 ， 为 了 提高 CPU 的 速度 ，CPU 有 一 
个 高 速 缓存 Cache。 在 高 速 缓存 中 ， 读 写 数 据 的 最 小 单位 为 缓存 行 
(Cache Line) ， 它 是 从 主 存 (memory) 复制 到 缓存 (Cache) 的 最 小 
单位 ， 一 般 为 32 字 节 到 128 字 节 。 








如 果 两 个 变量 存放 在 一 个 缓存 行 中 时 ， 在 多 线程 访问 中 ， 可 能 会 相 
互 影 响 彼 此 的 性 能 。 如 图 5.4 所 示 ， 假 设 X 和 Y 在 同一 个 缓存 行 。 运 行 在 
CPU1 上 的 线程 更 新 了 X， 那 么 CPU2 上 的 缓存 行 就 会 失效 ， 同 一 行 的 Y 
即使 没有 修改 也 会 变 成 无 效 ， 导 致 Cache 无 法 命中 。 接 着 ， 如 果 在 CPU2 
上 的 线程 更 新 了 Y， 则 导致 CPPU1 上 的 缓存 行 义 失效 (此 时 ， 同 一 行 的 X 
又 变 得 无 法 访问 ) 。 这 种 情况 反 反 复 复发 生 ， 无 疑 是 一 个 潜在 的 性 能 杀 
手 。 如 果 CPU 经 常 不 能 命中 缓存 ， 那 么 系统 的 吞吐 量 就 会 急剧 下 降 。 
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图 5.4 X 和 Y 在 同一 个 缓存 行 中 





为 了 使 这 种 情况 不 发 生 ， 一 种 可 行 的 做 法 就 是 在 X 变 量 的 前 后 空间 
都 先 占据 一 定 的 位 置 〈《 把 它 叫 做 padding 吧 ， 用 来 填充 用 的 ) 。 这 样 ， 
当 内 存 被 读 入 缓存 中 时 ， 这 个 缓存 行 中 ， 只 有 X 一 个 变量 实际 是 有 效 














的 ， 因 此 束 不 会 发 生 多 个 线程 同时 修改 缓存 行 中 不 同 变量 而 导致 变量 全 
体 失 效 的 情况 ， 如 图 5.5 所 示 。 
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为 了 实现 这 个 目的 ， 我 们 可 以 这 么 做 : 
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图 5.5 变量 X 和 Y 各 占据 一 个 缓冲 行 
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01 public final class FalseSharing implements Runnable { 


02 
03 
04 
05 
06 
07 


public final static int NUM_THREADS 
public final static long ITERATIONS 


private final int arrayIndex; 


private static VolatileLong[] longs 


static { 


2; // change 
500L * 1000L * 1000L 


new VolatileLong[NUM 


08 
09 
10 
de 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 
32 
33 
34 


for (int i = 0; i < longs.length; i++) { 


longs[i] = new VolatileLong(); 


public FalseSharing(final int arrayIndex) { 


this.arrayIndex = arrayIndex; 


public static void main(final String[] args) throws Except 
final long start = System.currentTimeMillis(); 
runTest(); 


System.out.printin("duration = " + (System.currentTime 


private static void runTest() throws InterruptedException 
Thread[] threads = new Thread[NUM_THREADS]; 
for (int i = 0; i < threads.length; i++) { 


threads[i] = new Thread(new FalseSharing(i)); 


for (Thread t : threads) { 


t.start(); 


for (Thread t : threads) { 


35 t.join(); 


36 } 

37 } 

38 

39 public void run() { 

40 long i = ITERATIONS + 1; 

41 while (0 != --i) { 

42 longs[arrayIndex].value = i; 

43 } 

44 } 

45 

46 public final static class VolatileLong { 
47 public volatile long value = OL; 

48 public long p1, p2, p3, p4, p5, p6,p7; // comment out 
49 } 

50 } 


这 里 我 们 使 用 两 个 线程 ， 因 为 我 的 计算 机 是 双核 的 ， 大 家 可 以 根据 
自己 的 硬件 配置 修改 参数 NUM_THREADS (第 2 行 )。 我 们 准备 一 个 数 
组 longs (第 6 行 )， 数 组 元 素 个 数 和 线程 数量 一 致 。 每 个 线程 都 会 访问 
自己 对 应 的 longs 中 的 元 素 〈 从 第 42 行 、 第 27 行 和 第 14 行 可 以 看 到 这 一 
Oe 


最 后 ， 最 关键 的 一 点 就 是 VolatileLong。 在 第 48 行 ， 准 备 了 7 个 long 
型 变量 用 来 填充 组 在。 实际 上 ， 只 有 VolatileLong.value 是 会 被 使 用 的 。 
而 那些 p1、p2 等 仅仅 用 于 将 数组 中 第 一 个 VolatileLong.value 和 第 二 个 
VolatileLong.value 分 开 ， 防 止 它们 进入 同一 个 缓存 行 。 





这 里 ， 我 使 用 JDK7 64 位 的 Java 虚 拟 机 ， 执 行 上 述 程序 ， 输 出 如 
下 : 


duration = 5207 


这 说 明 系 统 花 费 了 5 秒 钟 完成 所 有 的 操作 。 如 果 我 注释 挥 第 48 行 ， 
也 就 是 允许 系统 中 两 个 VolatileLong.value 放 置 在 同一 个 缓存 行 中 ， 程 序 
输出 如 下 : 


duration = 13675 
很 明显 ， 第 48 行 的 填充 对 系统 的 性 能 是 非常 有 帮助 的 。 


JER: 由 于 各 个 JDK 版 本 内 部 实现 不 一 致 ， 在 某 些 JDK 版 本 中 〈 比 如 
JDK 8) ， 会 自动 优化 不 使 用 的 字段 。 这 将 直接 导致 这 种 padding 的 
伪 共 享 解决 方案 失效 。 更 多 详细 内 容 大 家 可 以 参考 第 6 章 中 有 关 
LongAddr 的 介绍 。 


Disruptor 框 架 充分 考虑 了 这 个 问题 ， 它 的 核心 组 件 Sequence 会 被 非 
常 频 繁 的 访问 (每 次 入 队 ， 它 都 会 被 加 1) ， 其 基本 结构 如 下 : 


class LhsPadding 


{ 
protected long pi, p2, p3, p4, p5, p6, p7; 


class Value extends LhsPadding 


{ 


protected volatile long value; 


class RhsPadding extends Value 


{ 
protected long p9, p10, p11, p12, p13, p14, p15; 
jp 
ublic class Sequence extends RhsPadding{ 
// 省 略 具体 实现 
t 


虽然 在 Sequence 中 ， 主 要 使 用 的 只 有 value。 但 是 ， 通 过 LhsPadding 
和 RhsPadding， 在 这 个 value 的 前 后 安置 了 一 些 占 位 空间 ， 使 得 value 可 以 
无 冲突 的 存在 于 绥 存 中 。 








此 外 ， 对 于 Disruptor 的 环形 缓冲 区 RingBuffer， 它 内 部 的 数组 是 通 
过 以 下 语句 构造 的 : 


this.entries = new Object[sequencer.getBufferSize() + 2 * BUFFER _ 


大 家 注意 ， 实 际 产生 的 数组 大 小 是 缓冲 区 实际 大 小 再 加 上 两 倍 的 
BUFFER_PAD。 这 就 相当 于 在 这 个 数组 的 头 部 和 尾部 两 段 各 增加 了 
BUFFER_PAD 个 填充 ， 使 得 整个 数组 被 载 入 Cache 时 不 会 受到 其 他 变量 
的 影响 而 失效 。 


5.5 Futuretixt 





Future 模 式 是 多 线程 开 太 中 非 第 第 见 的 一 种 设计 模式 ， 它 的 核心 思 
想 是 腊 步 调用 。 当 我 们 需要 调用 一 个 函数 方法 时 ， 如 果 这 个 函数 执行 很 
慢 ， 那 么 我 们 就 要 进行 等 待 。 但 有 时 候 ， 我 们 可 能 并 不 急 着 要 结果 。 因 
此 ， 我 们 可 以 让 被 调 者 立即 返回 ， 让 它 在 后 人 台 慢 慢 处 理 这 个 请 求 。 对 于 
调用 者 来 说 ， 则 可 以 先 处 理 一 些 其 他 任务 ， 在 真正 需要 数据 的 场合 再 去 
尝试 获得 需要 的 数据 。 











Future 模 式 有 点 类 似 在 网 上 买 东 西 。 如 果 我 们 在 网 上 下 单 买 了 一 个 
手机 ， 当 我 们 文 付 完成 后 ， 手 机 并 没有 办 法 立即 送 到 家 里 ， 但 是 在 电脑 
上 会 立即 产生 一 个 订单 。 这 个 订单 融 是 将 来 发 货 或 者 领取 手机 的 重要 赁 
证 ， 这 个 攒 证 也 就 是 Future 模 式 中 会 给 出 的 一 个 契约 。 在 文 付 活动 结 
后 ， 大 家 不 会 傻 傻 地 等 着 手机 到 来 ， 而 是 可 以 各 忙 各 的。 而 这 张 订单 束 
成 为 了 商家 配 货 、 发 货 的 驱动 力 。 当 然 ， 这 一 切 你 并 不 用 关心 。 你 要 做 
的 ， 只 是 在 快递 上 门 时 ， 开 一 下 门 ， 拿 一 下 货 而 已 。 

















对 于 Future 模 式 来 说 ， 虽 然 它 无 法 立即 给 出 你 需要 的 数据 。 但 是 ， 
已 会 返回 给 你 一 个 提 约 ， 将 来 ， 你 可 以 凭借 肴 这 个 契约 去 重新 获取 你 需 


要 的 信息 。 





如 图 5.6 所 示 ， 显 示 了 通过 传统 的 同步 方法 ， 调 用 一 段 比较 耗 时 的 
程序 。 客 户 端 发 出 call 请 求 ， 这 个 请 求 需要 相当 长 一 段 时 间 才 能 返回 。 
客户 端 一 直 等 待 ， 直 到 数据 人 返回， 随后， 再 进行 其 他 任务 的 处 理 。 


call other_call 
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call_return other_call_retum 














图 5-6 传统 串 行 程序 调用 流程 


使 用 Future 模 式 蔡 换 原 来 的 实现 方式 ， 可 以 改进 其 调用 过 程 ， 如 图 
5.7 所 示 。 
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图 5-7 Future 模式 流程 图 


下 面 的 模型 展示 了 一 个 广义 Future 模 式 的 实现 ， 从 Data_Future 对 象 
可 以 看 到 ， 虽 然 call 本 身 仍 然 需要 很 长 一 段 时 间 处 理 程 序 。 但 是 ， 服 务 
程序 不 等 数据 处 理 完 成 便 立 即 返回 客户 端 一 个 伪造 的 数据 〈 相 当 于 丙 品 
的 订单 ， 而 不 是 商品 本 身 ) ， 实 现 了 Future 模 式 的 客户 端 在 拿 到 这 个 返 
回 结 果 后 ， 并 不 急于 对 其 进行 处 理 ， 而 去 调用 了 其 他 业务 逻辑 ， 充 分 利 
用 了 等 待 时 间 ， 这 束 是 Future 模 式 的 核心 所 在 。 在 完成 了 其 他 业务 逻辑 
的 处 理 后 ， 最 后 再 使 用 返回 比较 慢 的 Future 数 据 。 这 样 ， 在 整个 调用 过 
程 中 ， 就 不 存在 无 谓 的 等 待 ， 充 分 利用 了 所 有 的 时 间 片 段 ， 从 而 提高 系 
统 的 啊 应 速度 。 











5.5.1 Future 模式 的 主要 角色 





为 了 让 大 家 能 够 更 清晰 地 认识 Future 模 式 的 基本 结构 。 在 这 里 ， 我 


给 出 一 个 非常 简单 的 Future 模 式 的 实现 ， 它 的 主要 参与 者 如 表 5.2 所 示 。 


表 5.2 Future 模式 的 主要 参与 者 









































参与 者 作用 

Main 系统 启动 ， 调 用 Client 发 出 请 求 

Client 返回 Data 对 象 ， 立 即 返 回 FutureData， 并 开启 ClientThread 线 程 装配 RealData 
Data 返回 数据 的 接 

FutureData Future 数 据 ， 构 造 很 快 ， 但 是 是 一 个 虚拟 的 数据 ， 需 要 装配 RealData 
RealData 真实 数据 ， 其 构造 是 比较 慢 的 























它 的 核心 结构 如 图 5.8 所 示 。 





FutureData 





- isReady : boolean 











+ setRealData (RealData realData) : void 
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~- content : String 
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+ request (String queryStr) : Date i 
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图 5.8 ”Future 模式 结构 图 


5.5.2 ”Euture 模 式 的 简单 实现 





在 这 个 实现 中 ， a eae OME A Pn Ais RAY BK 
据 。 在 Future 模 式 中 ， 这 个 Data 接 口 有 两 个 重要 的 实现 ， 分 别 是 
RealData， 也 就 是 真实 数据 ， 这 就 是 我 们 最 终 雷 要 获得 的 ， 有 价值 的 信 
居 。 男 外 一 个 就 是 FutureData， 它 束 是 用 来 提取 RealData 的 一 个 “订单 ”。 














因此 FutureData 是 可 以 立即 返回 得 到 的 。 


下 面 是 Data 接 口 : 


public interface Data { 


public String getResult (); 


FutureData 实 现 了 一 个 快速 返回 的 RealData 包 装 。 它 只 是 一 个 包 
装 ， 或 者 说 是 一 个 RealData 的 虚拟 实现 。 因 此 ， 它 可 以 很 快 被 构造 并 返 
回 。 当 使 用 FutrueData 的 时 ， 如 果实 际 的 数据 没有 准备 
好 ， 那 么 程序 就 会 阻塞 ， 等 待 RealData 准 备 好 并 注入 到 FutureData 中 ， 
才 最 终 返 回 数据 。 


YER: FutureData 是 Future 模 式 的 关键 。 它 实际 上 是 真实 数据 
RealData 的 代理 ， 封 装 了 获取 RealData 的 等 待 过 程 。 


public class FutureData implements Data { 
protected RealData realdata = null; //FutureDatasel 
protected boolean isReady = false; 
public synchronized void setRealData(RealData realdata) { 
if (isReady) { 
return; 
} 
this.realdata = realdata; 
isReady = true; 


notifyAl1(); /V/RealData 已 经 忆 


public synchronized String getResult() { // 会 等 待 RealDat 
while (!isReady) { 
try { 
wait(); // 一 直 等 待 ， 知 道 
} catch (InterruptedException e) { 
上 


} 
return realdata.result; // 由 RealData 实 E 











RealData 是 最 终 需 要 使 用 的 数据 模型 。 它 的 构造 很 慢 。 在 这 里 ， 使 
用 sleep0 〇 函数 模拟 这 个 过 程 ， 简 单 地 模拟 一 个 字符 串 的 构造 。 


public class RealData implements Data { 
protected final String result; 
public RealData(String para) { 
//RealData 的 构造 可 能 很 慢 ， 需 要 用 户 等 待 很久 ， 这 里 使 用 Sleep 模拟 
StringBuffer sb=new StringBuffer(); 








for (int i = 0; < 10; itt) { 
sb.append(para); 
try { 
// 这 里 使 用 sleep， 代 蔡 一 个 很 慢 的 操作 过 程 
Thread.sleep(100) ; 


} catch (InterruptedException e) { 
} 


result =sb.toString(); 
} 
public String getResult() { 


return result; 


接 下 来 就 是 我 们 的 客户 端 程 序 ，Client 主 要 实现 了 获取 FutureData， 
并 开启 构造 RealData 的 线程 。 并 在 接受 请 求 后 ， 很 快 的 返回 
FutureData。 注 意 ， 它 不 会 等 竺 数据 真 的 构造 完毕 再 返回 ， 而 是 立即 返 
回 FutureData， 即 使 这 个 时 候 FutureData 内 并 没有 真实 数据 。 





public class Client { 
public Data request(final String queryStr) { 
final FutureData future = new FutureData(); 
new Thread() { 
public void run() { // RealData 的 构建 和 
// 所 以 在 单独 的 线程 中 


RealData realdata = new RealData(queryStr); 





future.setRealData(realdata) ; 


} 
}.start(); 


return future; // FutureData 会 被 i 


最 后 ， 就 是 我 们 的 主 函数 Main， 它 主要 负责 调用 Client 发 起 请 求 ， 
并 消费 返回 的 数据 。 


public static void main(String[] args) { 
Client client = new Client(); 


// 这 里 会 立即 返回 ， 因 为 得 到 的 是 FutureData 而 不 是 RealData 





Data data = client.request("name"); 
System.out.printlLn(" 请 求 完毕 " ) ; 
try { 
// 这 里 可 以 用 一 个 sleep 代 蔡 了 对 其 他 业务 逻辑 的 处 理 
// 在 处 理 这 些 业 务 逻辑 的 过 程 中 ，RealData 被 创建 ， 从 而 充分 利用 了 等 待 时 间 
Thread.sleep(2000); 



































} catch (InterruptedException e) { 


} 
// 使 用 真实 的 数据 
System.out.printlLn(" 数 据 = " + data.getResult()); 


5.5.3 JDK 中 的 Future 模式 


Future 模 式 是 如 此 常用 ， 因 此 JDK 内 部 已 经 为 我 们 准备 好 了 一 套 完 
整 的 实现 。 显 然 ， 这 个 实现 要 比 我 们 前 面 提 出 的 方案 复杂 得 多 。 在 这 
里 ， 我 们 将 简单 向 大 家 介绍 一 下 它 的 使 用 方式 。 





首先 ， 让 我 们 看 一 下 Future 模 式 的 基本 结构 ， 如 图 5.9 所 示 。 其 中 
Future 接 口 就 类 似 于 前 文 描 述 的 订单 或 者 说 是 契约 。 通 过 它 ， 你 可 以 得 
到 真实 的 数据 。RunnableFuture 继 承 了 Future 和 Runnable 两 个 接口 ， 其 中 
run() 方 法 用 于 构造 真实 的 数据 。 它 有 一 个 具体 的 实现 FutureTask 类 。 
FutureTask 有 一 个 内 部 类 Sync， 一 些 实 质 性 的 工作 ， 会 委托 Sync 类 实 





现 。 而 Sync 类 最 终 会 调用 Callable 接 口 ， 完 成 实际 数据 的 组 装 工作 。 
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图 5.9 JDKA E WFuture A 





Callable 接 口上 只 有 一 个 方法 call0， 它 会 返回 需要 构造 的 实际 数据 。 
这 个 Callable 接 口 也 是 这 个 Future 框 架 和 应 用 程序 之 间 的 重要 接口 。 如 果 
我 们 要 实现 自己 的 业务 系统 ， 通 常 需 要 实现 上 自己 的 Callable 对 象 。 此 
外 ，FutureTask 类 也 与 应 用 密切 相关 ， 通 常 ， 我 们 会 使 用 Callable 实 例 构 
造 一 个 FutureTask 实 例 ， 并 将 它 提交 给 线程 池 。 











下 面 我 们 将 展示 这 个 内 置 的 Future 模 式 的 使 用 : 


01 public class RealData implements Callable<String> { 


02 private String para; 

03 public RealData(String para){ 

04 this.para=para; 

05 } 

06 @Override 

07 public String call() throws Exception { 


08 


09 StringBuffer sb=new StringBuffer(); 


10 Tor (dme y= OF 1 < 107 I) 

11 sb.append(para); 

12 cry 

13 Thread.sleep(100); 

14 } catch (InterruptedException e) { 
15 } 

16 } 

17 return sb.toString(); 

18 } 

19 } 


上 述 代码 实现 了 Callable 接 口 ， 它 的 call(0 方 法 会 构造 我 们 需要 的 真 
实数 据 并 返回 。 当 然 这 个 过 程 可 能 是 缓慢 的 ， 这 里 使 用 Thread.sleep0 模 
拟 它 : 





01 public class FutureMain { 





02 public static void main(String[] args) throws InterruptedE 
03 // 构 造 FutureTask 

04 FutureTtask<String> future = new FutureTask<String> (ır 
05 ExecutorService executor = Executors.newFixedThreadPoo 
06 // 执 行 EutureTask， 相 当 于 上 例 中 的 client.request("a") Kiki 
07 // 在 这 里 开启 线程 进行 RealData 的 call( ) 执 行 

08 executor.submit(future) ; 

09 

10 System.out,.printlLn(" 请 求 完毕 ") ， 


也 也 try { 


12 // 这 里 依然 可 以 做 额外 的 数据 操作 ， 这 里 使 用 sleep 代 蔡 其 他 业务 逻辑 的 ， 














13 Thread.sleep(2000); 

14 } catch (InterruptedException e) { 

15 } 

16 // 相 当 于 5 .5.2 节 中 得 data.getResult ()， 取 得 call( ) 方 法 的 返回 人 
17 // 如 果 此 时 call( ) 方 法 没有 执行 完成 ， 则 依然 会 等 待 

18 System.out.println(" 数 据 = " + future.get()); 

19 } 

20 } 


上 述 代码 就 是 使 用 Future 模 式 的 典型 。 第 4 行 ， 构 造 了 FutureTask 对 
象 实例 ， 表 示 这 个 任务 是 有 返回 值 的 。 构 造 FutureTask 时 ， 使 用 Callable 
接口 ， 告 诉 FutureTask 我 们 需要 的 数据 应 该 如 何 产生 。 接 痢 再 第 8 行 ， 将 
FutureTask 提 交 给 线程 池 。 显 然 ， 作 为 一 个 简单 的 任务 提交 ， 这 里 必然 
是 立即 返回 的 ， 因 此 程序 不 会 阻塞 。 接 下 来 ， 我 们 不 用 关心 数据 是 如 何 
产生 的 。 可 以 去 做 一 些 额 外 的 事情 ， 然 后 在 需要 的 时 候 可 以 通过 
Future.get() (3818747) 得 到 实际 的 数据 。 


除了 基本 的 功能 外 ，JDK 还 为 Future 接 口 提供 了 一 些 简单 的 控制 功 


能 : 

boolean cancel(boolean mayInterruptIfRunning); // 取 消 人 
boolean isCancelled(); // 是 否 E 
boolean isDone(); // 是 否 E 


V get() throws InterruptedException, ExecutionException; // 取 得 i 


V get(long timeout, TimeUnit unit) // 取 得 


5.6 ”并 行 流水 线 


并 发 算法 虽然 可 以 充分 发 挥 多 核 CPU 的 性 能 。 但 不 幸 的 是 ， 并 非 所 
有 的 计算 都 可 以 改造 成 并 发 的 形式 。 那 什么 样 的 算法 是 无 法 使 用 并 发 进 
行 计算 的 呢 ? 简单 来 说 ， 执 行 过 程 中 有 数据 相关 性 的 运算 都 是 无 法 完美 
并 行 化 的 。 





假如 现在 有 两 个 数 ，B 和 C。 如 果 我 们 要 计算 (B+C)*B/2， 那 么 这 个 
运行 过 程 就 是 无 法 并 行 的 。 原 因 是 ， 如 果 B+C 没 有 执行 完成 ， 则 永远 算 
不 出 (B+C)*B， 这 就 是 数据 相关 性 。 如 果 线 程 执 行 时 ， 所 需 的 数据 存在 
这 种 依赖 关系 ， 那 么 ， 就 没有 办 法 将 它们 完美 的 并 行 化 。 如 图 5.10 所 
示 ， 诠 释 了 这 个 道理 。 


(B+C)*xB/2 








一 、 | |2 2 WP a 
kT BEC LA RY AA 
图 5. 10 ” (B+C)*B/2 无 法 并 行 化 


那 遇 到 这 种 情况 时 ， 有 没有 什么 补救 措施 呢 ? Be A EN, AB 
是 借鉴 日 常生 产 中 的 流水 线 思 想 。 


比如 ， 现 在 要 生产 一 批 小 玩偶 。 小 玩偶 的 制作 分 为 四 个 步骤 ， 第 一 


要 组 闭 身 体 ， 第 二 要 在 号 体 上 安装 四 及 和 头 部 ， 第 三 ， 给 组 闭 完 成 的 玩 
偶 罕 上 一 件 床 亮 的 衣服 ， 第 四 ， 惑 可 以 包 厂 出 渍 了。 为 了 加 快 制作 玩具 
的 进度 ， 我 们 不 可 能 叫 四 个 人 同时 加 工 一 个 玩具 ， 因 为 这 四 个 步骤 有 痢 
严重 的 依赖 关系 。 如 果 没 有 身体 ， 惑 没有 地 方 安 效 四 胶 ， 如 果 没 有 组 装 
Fe, WARE AK, WRIA ERR, BANGER AG. Al, R 
四 个 人 来 做 一 个 玩偶 是 坚 无 意义 的 。 

















但 是 ， 如 果 你 现在 要 制作 的 不 是 1 只 玩偶 ， 而 是 1 万 只 玩 俩 ， 那 情况 
就 不 同 了 。 你 可 以 找 四 个 人 ， 第 一 个 人 只 负责 组 朔 身 体 ， 完 成 后 交 给 第 
二 个 人 ;第 二 个 人 只 负责 安装 头 部 和 四 胶 ， 交 付 第 三 人 ; 第 三 人 只 负责 
穿 衣服 ， 并 交付 第 四 人 ; 第 四 人 只 负责 包装 发 货 。 这 样 所 有 人 都 可 以 一 
起 工作 ， 共 同 完 成 任务 ， 而 整个 时 间 周 期 也 能 缩短 到 原来 的 1/4 左 右 ， 
这 就 是 流水 线 的 思想 。 一 旦 流水 线 满载 ， 每 次 只 需要 一 步 〈 假 设 一 个 玩 
偶 需 要 四 步 ) 就 可 以 产生 一 个 玩偶 ， 如 图 5.11 所 示 。 
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图 5. 11 使 用 流水 线 生 产 玩偶 


类 似 的 思想 可 以 借鉴 到 程序 开发 中 。 即 使 (B+C)*B/2 无 法 并 行 ， 但 
是 如 果 你 需要 计算 一 大 堆 B 和 C 的 值 ， 你 依然 可 以 将 它 流水 化 。 首 先 将 


计算 过 程 拆 分 为 三 个 步 又 : 


P1:A=B+C 
P2:D=AxB 
P3:D=D/2 


上 述 步 骤 中 P1、P2 和 P3 均 在 单独 的 线程 中 计算 ， 并 且 每 个 线程 只 负 
中 自己 的 工作 。 此 时 ，P3 的 计算 结果 就 是 最 终 需 要 的 答案 。 











P1 接 收 B 和 C 的 值 ， 并 求 和 ， 将 结果 输入 给 P2。P2 求 乘积 后 输入 给 
P3。P3 将 D 除 以 2 得 到 最 终 值 。 一 旦 这 条 流水 线 建 立 ， 只 需要 一 个 计算 
步骤 就 可 以 得 到 (B+C)*B/2 的 结果 。 





为 了 实现 这 个 功能 ， 我 们 需要 定义 一 个 在 线程 间 携 市 结果 进行 信息 
交换 的 载体 : 


public class Msg { 
public double i; 
public double j; 
public String orgStr=null; 


P1 计 算 的 是 加 法 : 


01 public class Plus implements Runnable { 

02 public static BlockingQueue<Msg> bq=new LinkedBlockingQue 
03 @Override 

04 public void run() { 

05 while(true){ 


06 try { 


07 Msg msg=bq.take(); 

08 msg.j=msg.i+msg.j; 

09 Multiply.bq.add(msg); 

10 } catch (InterruptedException e) { 
11 } 

12 } 

13 } 

14 } 


ERAP, PIRRE SPATS ERTEBLIMsg, HITRA, Ka 
末 传 递 给 乘法 线程 P2《〈 第 9 行 ) 。 当 没有 数据 再 要 处 理 时 ，P1 进 行 等 


ÍF o 


P2 计 算 乘 法 : 
01 public class Multiply implements Runnable { 
02 public static BlockingQueue<Msg> bq = new LinkedBlockingę 
03 
04 @Override 
05 public void run() { 
06 while (true) { 
07 try { 
08 Msg msg = bq.take(); 
09 msg.i = msg.i * msg.j; 
10 Div.bq.add(msg); 
11 } catch (InterruptedException e) { 


12 } 


和 P1 非 党 类 似 ，P2 计 算 相 乘 结 末 后 ， 将 中 间 结 来 传递 给 除法 线程 
P3。 





01 public class Div implements Runnable { 

02 public static BlockingQueue<Msg> bq = new LinkedBlockingę 
03 

04 @Override 

05 public void run() { 

06 while (true) { 

07 try { 

08 Msg msg = bq.take(); 

09 msg.i = msg.i / 2; 

10 System.out.println(msg.orgStr + "=" + msg.1); 
11 } catch (InterruptedException e) { 

12 } 

13 } 

14 } 

lS y 


P3 将 结果 除 以 2 后 输出 最 终 的 结果 。 





最 后 是 提交 任务 的 主线 程 ， 这 里 ， 我 们 提交 100 万 个 请 求 ， 让 线程 


组 进行 计算 : 


01 public class PStreamMain { 


02 public static void main(String[] args) { 
03 new Thread(new Plus()).start(); 

04 new Thread(new Multiply()).start(); 

05 new Thread(new Div()).start(); 

06 

07 for (Gimet 1 = í; 1 <= 1000; Is) 4 

08 ror (Gine J = 1; J <= 1000: Jr) 4 
09 Msg msg = new Msg(); 

10 msg.i = 1; 

lal msg.j = j; 

12 MSGR ORGS ra OC ak A cea eek ere 
13 Plus.bq.add(msg); 

14 } 

15 } 

16 } 

17 } 


上 述 代码 第 13 行 ， 将 数据 提交 给 P1 加 法 线程 ， 开 启 流 水 线 的 计算 。 
在 多 核 或 者 分 布 式 场景 中 ， 这 种 设计 思路 可 以 有 效 地 将 有 依赖 关系 的 操 
作 分 配 在 不 同 的 线程 中 进行 计算 ， 尽 可 能 利用 多 核 优 势 。 





57 “并行 搜 索 


搜索 是 几乎 每 一 个 软件 都 必 不 可 少 的 功能 。 对 于 有 序数 据 ， 通 名 可 
以 采用 二 分 碍 找 法 。 对 于 无 序数 据 ， 则 只 能 挨个 查找 。 在 本 节 中 ， 我 们 
将 讨论 有 关 并 行 的 无 序数 组 的 搜索 实现 。 








给 定 一 个 数组 ， 我 们 要 奉 找 满足 条 件 的 元 系 。 对 于 串 行 程序 来 说 ， 
只 要 遍历 一 下 数组 就 可 以 得 到 结果 。 但 如 果 要 使 用 并 行 方式 ， 则 需要 和 额 
外 增加 一 些 线程 间 的 通信 机 制 ， 使 各 个 线程 可 以 有 效 地 运行 。 





一 种 简单 的 策略 就 是 将 原始 数据 集合 按照 期 望 的 线程 数 进行 分 割 。 
如 琳 我 们 计划 使 用 两 个 线程 进行 搜索 ， 那 么 就 可 以 把 一 个 数组 或 集合 分 
割 成 两 个 。 每 个 线程 各 上 自 独 立 搜索 ， 当 其 中 有 一 个 线程 找到 数据 后 ， 苹 
即 返 回 结果 即 可 。 


现在 假设 有 一 个 整 型 数组 ， 我 们 需要 得 找 数组 内 的 元 又 : 
static int[] arr; 


定义 线程 池 、 线 程 数 量 以 及 存放 结果 的 变量 result。 在 result 中 ， 我 
们 会 保存 符合 条 件 的 元 素 在 arr 数 组 中 的 下 标 。 默 认为 -1， 表 示 没 有 找到 
给 定 元 素 。 


static ExecutorService pool = Executors.newCachedThreadPool(); 
static final int Thread_Num=2; 


static AtomicInteger result=new AtomicInteger(-1); 


并 发 搜索 会 要 求 每 个 线程 查找 arr 中 的 一 段 ， 因 此 ， 搜 索 函 数 必 须 指 


定 线程 需要 搜索 的 起 始 和 纺 束 位 置 : 


01 public static int search(int searchValue,int beginPos,int endP 


02 int i=0; 

03 for (i=beginPos;i<endPos;it+t+) { 

04 if(result.get()>=0){ 

05 return result.get(); 

06 } 

07 if(arr[i] == searchValue){ 

08 // 如 果 设 置 失败 ， 表 示 其 他 线程 已 经 先 找 到 了 
09 if(!result.compareAndSet(-1, i)){ 
10 return result.get(); 

11 } 

12 return i; 

13 } 

14 } 

15 return -1; 

16 } 


上 述 代码 第 4 行 ， 首 先 通 过 result 判 断 是 否 已 经 有 其 他 线程 找到 了 需 
要 的 结果 。 如 果 已 经 找到 ， 则 立即 返回 不 再 进行 查找。 如 果 没 有 找到 ， 
则 进行 下 一 步 搜索 。 第 7 行 代码 成 立 则 表示 当前 线程 找到 了 需要 的 数 
据 ， 那 么 就 会 将 结果 保存 到 result 变 量 中 。 这 里 使 用 CAS 操 作 ， 如 果 设 置 
失败 ， 则 表示 其 他 线程 已 经 先 我 一 步 找到 了 结果 。 因 此 ， 可 以 无 视 失败 
的 情况 ， 找 到 结果 后 ， 进 行 返 回 。 





定义 一 个 线程 进行 查找 ， 它 会 调用 前 面 的 pSearch() 方 法 : 


01 public static class SearchTask implements Callable<Integer > { 


02 int begin, end, searchValue; 

03 public SearchTask(int searchValue, int begin, int end){ 
04 this.begin=begin; 

05 this.end=end; 

06 this.searchValue=searchValue; 

07 } 

08 public Integer call(){ 

09 int re= search(searchValue, begin, end) ; 
10 return re; 

11 } 

12 } 





最 后 是 pSearch() 并 行 查 找 函 数 ， 它 会 根据 线程 数量 对 arr 数 组 进行 划 
分 ， 并 建立 对 应 的 任务 提交 给 线程 池 处 理 : 


01 public static int pSearch(int searchValue) throws InterruptedE 


ExecutionException{ 

02 int subArrSize=arr.length/Thread_Num+1; 

03 List<Future<Integer>> re=new ArrayList<Future<Integer > 
04 for(int 1=0;i<arr.length;1i+=subArrSize) { 

05 int end = i+subArrSize; 

06 if(end>=arr.length)end=arr.length; 

07 re.add(pool.submit(new SearchTask(searchValue,i,end) )) 
08 } 

09 for(Future<Integer> fu:re){ 


10 if(fu.get()>=0)return fu.get(); 


sl } 


12 return -1; 


上 述 代码 中 使 用 了 JDK 内 置 的 Future 模 式 ， 其 中 第 4 一 8 行将 原始 数 
组 arr 划 分 为 看 干 段 ， 并 根据 划分 结 末 建立 子 任务 。 每 一 个 子 任务 都 会 返 
回 一 个 Future 对 象 ， 通 过 Future 对 象 可 以 获得 线程 组 得 到 的 最 终结 果 。 
在 这 里 ， 由 于 线程 之 间 通 过 result 共 享 彼 此 的 信息 ， 因 此 只 要 当 一 个 线 
程 成 功 返 回 后 ， 其 他 线程 都 会 立即 返回 。 因 此 ， 不 会 出 现 由 于 排 在 前 面 
的 任务 长 时 间 无 法 结束 而 导致 整个 搜索 结果 无 法 立即 获取 的 情况 。 














5.8 并行 排序 


排序 是 一 项 非常 利用 的 操作 。 你 的 应 用 程序 在 运行 时 ， 可 能 无 时 无 
刻 不 在 进行 排序 操作 。 排 序 的 算法 有 很 多 ， 但 在 这 里 我 并 不 打算 一 一 介 
绍 它 们 。 对 于 大 部 分 排序 算法 来 说 ， 都 是 串 行 执行 的 。 当 排序 元 系 很 多 
时 ， 知 使 用 并 行 算法 代 答 串 行 算法 ， 显 然 可 以 更 加 有 效 地 利用 CPU。 但 
将 单行 算法 改造 成 并 行 算 法 并 非 易 事 ， 甚 至 会 极 大 地 增加 原 有 算法 的 复 
杂 上 度 。 在 这 里 ， 我 将 介绍 几 种 相对 简单 的 ， 但 是 也 足以 让 人 脑 洞 大 开 的 
平行 排序 算法 。 


5.8.1 分 离 数 据 相 关 性 ， 奇偶 交换 排 
序 


在 介绍 奇偶 排序 前， 首先 让 我 们 看 一 下 熟悉 的 冒 泡 排 序 。 在 这 里 ， 
假设 我 们 需要 将 数组 进行 从 小 到 大 的 排序 。 冒 泡 排 序 的 操作 很 类 似 水 中 
的 起 泡 上 浮 ， 在 冒 泡 排 序 的 执行 过 程 中 ， 如 末 数 据 较 小 ， 它 束 会 逐步 被 
交换 到 前 面 去 ， 相 反 ， 对 于 大 的 数字 ， 则 会 下 沉 ， 交 换 到 数组 的 末尾 。 
































冒 泡 排序 的 一 般 算法 如 下 : 


01 public static void bubbleSort(int[] arr) { 


02 for (int i = arr.length - 1; i > 0; i--) { 
03 FOr (anme a S 0) ee at 
04 ir (arti > arrij I L) 4 


05 int temp = arr[j]; 


06 arr) ="arr |) Ay 
07 arr[j + 1] = temp; 








2 4 S 6 $L 
图 5.12 冒 泡 排 序 迭 代 过 程 
大 家 可 以 看 到 ， 在 每 次 迭代 的 交换 过 程 中 ， 由 于 每 次 交换 的 两 个 元 
素 存 在 数据 冲突 ， 对 于 每 个 元 素 ， 它 既 可 能 与 前 面 的 元 素 交 换 ， 也 可 能 
和 后 面 的 元 素 交 换 ， 因 此 很 难 直接 改造 成 并 行 算法 。 








如 果 能 够 解 开 这 种 数据 的 相关 性 ， 就 可 以 比较 容易 地 使 用 并 行 算法 


来 实现 类 似 的 排序 。 奇 偶 交 换 排 序 天 是 基于 这 种 思想 的 。 





对 于 奇 倘 交换 排序 来 说 ， 它 将 排序 过 程 分 为 两 个 阶段 ， 奇 交换 和 偶 
BOHR MPAA, Ee ERAT BR | VAR PAB ETT o 
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图 5. 13 ”奇偶 交换 迭代 示意 图 
可 以 看 到 ， 由 于 将 整个 比较 交换 独立 分 割 为 奇 阶段 和 侦 阶 段 。 这 就 
使 得 在 每 一 个 阶段 内 ， 所 有 的 比较 和 交换 是 没有 数据 相关 性 的 。 因 此 ， 
每 一 次 比较 和 交换 都 可 以 独立 执行 ， 也 就 可 以 并 行 化 了 。 








下 面 是 奇偶 交换 排序 的 串 行 实现 : 


01 public static void oddEvenSort(int[] arr) { 


02 int exchFlag = 1, start = 0; 

03 while (exchFlag == 1 || start == 1) { 

04 exchFlag = 0; 

05 for (int i = start; i < arr.length - 1; i += 2) { 


06 if (arr[i] > arr[I + 1]) { 


07 int temp = arr[i]; 


08 arre = arr i iy 
09 arr[i + 1] = temp; 
10 exchFlag = 1; 

11 } 

12 } 

13 if (start == 0) 

14 start = 1 

15 else 

16 start = 0; 

17 } 

18 } 


其 中 ，exchFlag 用 来 记录 当前 迭代 是 否 发 生 了 数据 交换 ， 而 start 变 
量 用 来 表示 是 奇 交换 还 是 偶 交 换 。 初 始 时 ，start 为 0， 表 示 进 行 偶 交 
换 ， 每 次 欠 代 结束 后 ， 切 换 start 的 状态 。 如 果 上 一 次 比较 交换 发 生 了 数 
据 交 换 ， 或 者 当前 正在 进行 的 是 奇 交 换 ， 循 环 就 不 会 停止 ， 直 到 程序 不 
再 发 生 交 换 ， 并 且 当 前 进行 的 是 偶 交 换 为 止 〈《 表 示 和 奇偶 交换 已 经 成 对 出 
现 ) 。 














上 述 代码 虽然 是 串 行 代码 ， 但 是 已 经 可 以 很 方便 地 改造 成 并 行 模 
J: 


01 static int exchFlag=1; 

02 static synchronized void setExchFlag(int v){ 
03 exchFlag=v; 

04 } 


05 static synchronized int getExchFlag(){ 


06 
07 
08 
09 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 
32 


return exchFlag; 


public static class OddEvenSortTask implements Runnable{ 


Ito 
CountDownLatch latch; 
public OddEvenSortTask(int i,CountDownLatch latch) { 
this.i=i; 
this.latch=latch; 
} 
@Override 
public void run() { 
if (arr[i] > arr[i+41]) { 
int temp = arr[i]; 
arr[i] = arr[i + 1]; 
arr[i + 1] = temp; 
setExchFlag(1); 
} 


latch.countDown(); 


public static void pOddEvenSort(int[] arr) throws InterruptedE 


int start = 0; 

while (getExchFlag() == || start == 1) { 
setExchFlag(0); 
// 偶 数 的 数组 长 度 ， 当 start 为 1 时 ， 只 有 len/2-1 个 线程 


CountDownLatch latch = new CountDownLatch(arr.length/2 





33 for (int i = start; i < arr.length - 1; i += 2) { 





34 pool.submit(new OddEvenSortTask(i, latch) ); 
35 } 

36 // 等 待 所 有 线程 结 

37 latch.await(); 

38 if (start == 0) 

39 start = 1; 

40 else 

41 start = 0; 

42 } 

43 } 


上 述 代码 第 9 行 ， 定 义 了 奇偶 排序 的 任务 类 。 访 任务 的 主要 工作 是 
进行 数据 比较 和 必要 的 交换 《第 18 一 23 行 ) 。 并 行 排序 的 主体 是 
pOddEvenSort( 方 法 ， 它 使 用 CountDownLatch 记 录 线 程 数 量 ， 对 于 每 一 
次 欠 代 ， 使 用 单独 的 线程 对 每 一 次 元 素 比 较 和 交换 进行 操作 。 在 下 一 次 
欠 代 开始 前 ， 必 须 等 待 上 一 次 友 代 所 有 线程 的 完成 。 


5.8.2 ”改进 的 插入 排序 : 布尔 排序 


插入 排序 也 是 一 种 很 常用 的 排序 算法 。 它 的 基本 思想 是 : 一 个 未 排 
序 的 数组 〈 当 然 也 可 以 是 链表 ) 可 以 分 为 两 个 部 分 ， 前 半 部 分 是 已 经 排 
序 的 ， 后 半 部 分 是 未 排序 的 。 在 进行 排序 时 ， 只 需要 在 未 排序 的 部 分 中 
选择 一 个 元 素 ， 将 其 插入 到 前 面 有 序 的 数组 中 即 可 。 最 终 ， 未 排序 的 部 
分 会 越 来 越 少 ， 直 到 为 0， 那 么 排序 就 完成 了 。 初 始 时 ， 可 以 假设 已 排 
序 部 分 就 是 第 一 个 元 素 。 


























插入 排序 的 几 次 迭代 示意 如 图 5.14 所 示 。 
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图 5. 14 插入 排序 示意 图 


插入 排序 的 实现 如 下 所 示 : 


01 public static void insertSort(int[] arr) { 





02 int length = arr.length; 

03 int j, i, key; 

04 for (i = 1; i < length; i++) { 

05 //key 为 要 准备 插入 的 元 素 

06 key = arr[i]; 

07 J She Se 

08 while (j >= 0 && arr[j] > key) { 
09 arr[j + 1] = arr[j]; 

10 Jas; 

11 } 


12 // 找 到 合适 的 位 置 插入 Key 


13 arr[j + 1] = key; 








上 述 代码 第 6 行 ， 提 取 要 准备 插入 的 元 素 〈 也 就 是 未 排序 序列 中 的 
第 一 个 元 素 ) 。 接 着 ， 在 已 排序 队列 中 找到 这 个 元 素 的 插入 位 置 (第 8 
一 10 行 ) ， 并 进行 插入 《第 13 行 ) 即 可 。 


简单 的 插入 排序 是 很 难 并 行 化 的 。 因 为 这 一 次 的 数据 插入 依赖 于 上 
一 次 得 到 的 有 序 序 列 ， 因 此 多 个 步骤 之 间 无 法 并 行 。 为 此 ， 我 们 可 以 对 
插入 排序 进行 扩展 ， 这 就 是 希 尔 排序 。 








布尔 排序 将 整个 数组 根据 间隔 h 分 割 为 各 干 个 子 数组 。 子 数组 相互 
穿插 在 一 起 ， 每 一 次 排序 时 ， 分 别 对 每 一 个 子 数组 进行 排序 。 如 图 5.15 
所 示 ， 当 h 为 3 时 ， 和 希 尔 排序 将 整个 数组 分 为 交织 在 一 起 的 三 个 子 数组 。 
其 中 ， 所 有 的 方块 为 一 个 子 数组 ， 所 有 的 圆 形 、 三 角形 分 别 组 成 刃 外 两 
个 子 数组 。 每 次 排序 时 ， 总 是 交换 间隔 为 hn 的 两 个 元 素 。 


口 ]JolAlploeeIGIO 人 入 己 


h =) 








图 5. 15 ” h=3 时 的 数组 分 割 


在 每 一 组 排序 完成 后 ， 可 以 递减 h 的 值 ， 进 行 下 轮 更 加 精细 的 排 
序 。 直 到 h 为 1， 此 时 等 价 于 一 次 插入 排序 。 


布尔 排序 的 一 个 主要 优点 是 ， 即 使 一 个 较 小 的 元 素 在 数组 的 末尾 ， 
由 于 每 次 元 素 移动 都 以 h 为 间隔 进行 ， 因 此 数组 末尾 的 小 元 素 可 以 在 很 








少 的 交换 次 数 下 ， 就 被 置换 到 最 接近 元 系 最 终 位 置 的 地 方 。 
下 面 是 硕 尔 排序 的 串 行 实现 : 


01 public static void shellSort(int[] arr) { 
02 // 计算 出 最 大 的 h 值 


03 AME M S íle 

04 while (h <= arr.length / 3) { 

05 nn” 3 t ili 

06 } 

07 while (h > 0) { 

08 for (int 1 = h; i < arr.length; i++) { 
09 if (arr[i] < arr[i - h]) { 

10 int tmp = arr[i]; 

11 iNe J = L- h; 

12 while (j >= © && arr[j] > tmp) { 
13 arni +h] Eanna; 

14 j -=h; 

15 } 

16 arr[j + h] = tmp; 

17 } 

18 } 

19 // 计算 出 下 一 个 h 值 

20 ns Chl 7 8 

21 } 

220 


上 述 代 码 第 4 一 6 行 ， 计 算 一 个 合适 的 p 值 ， 接 着 正式 进行 希 尔 排 





序 。 第 8 行 的 for 循 环 进 行 间隔 为 h 的 插入 排序 ， 每 次 排序 结束 后 ， 递 减 h 
的 值 〈 第 20 行 ) 。 直 到 h 为 1， 退 化 为 插入 排序 。 


很 显然 ， 而 和 尔 排序 每 次 都 针对 不 同 的 子 数 组 进行 排序 ， 各 个 子 数组 
之 间 是 完全 独立 的 。 因 此 ， 很 容易 改写 成 并 行程 序 : 


01 public static class ShellSortTask implements Runnable { 


02 int i = 0; 

03 int h = 0; 

04 CountDownLatch 1; 

05 

06 public ShellSortTask(int i, int h, CountDownLatch latch) { 
07 this.i = 1; 

08 this.h = h; 

09 this.1 = latch; 

10 } 

11 

12 @Override 

13 public void run() { 

14 wl (erreka < arr gil [AS et 

15 int tmp = arr[i]; 

16 int J =1i-h; 

17 while (j >= 0 && arr[j] > tmp) { 
18 arr[j + h] = arr[j]; 

19 j -=h; 

20 } 


21 arr[j + h] = tmp; 


22 
23 
24 
25 
26 
27 
28 
29 
30 
31 
32 
33 
34 
35 
36 
37 
38 
39 
40 
41 
42 
43 
44 
45 
46 
47 
48 


} 


1.countDown(); 


public static void pShellSort(int[] arr) throws InterruptedExc 
// 计算 出 最 大 的 h 值 
me M = ale 
CountDownLatch latch = null; 
while (h <= arr.length / 3) { 
nana e r ads 
} 
while (h > 0) { 
System.out.println("h=" + h); 
ir (n >s A) 
latch = new CountDownLatch(arr.length - h); 
for (int i = h; i < arr.length; i++) { 
// 控制 线程 数量 
ir (n >= 4) 4 








pool.execute(new ShellSortTask(i, h, latch)); 
} else { 
if (arr[i] < arr[i - h]) { 
int tmp = arr[i]; 
int j S= Lo ny 
while (j >= © && arr[j] > tmp) { 


arr[j + h] = arr[j]; 


49 } 


50 arr[j + h] = tmp; 
51 } 

52 // System.out.println(Arrays.toString(arr)); 
53 } 

54 } 

55 // 等 待 线程 排序 完成 ， 进 入 下 一 次 排序 
56 latch.await(); 

57 // 计算 出 下 一 个 h 值 

58 h= (h - 1) / 3; 

59 } 

60 } 


上 述 代码 中 定义 ShellSortTask 作 为 并 行 任 务 。 一 个 ShellSortTask 的 
作用 是 根据 给 定 的 起 始 位 置 和 h， 对 子 数 组 进行 排序 ， 因 此 可 以 完全 并 
行 化 。 


为 控制 线程 数量 ， 这 里 定义 并 行 主 函 数 pShellSort0) 在 h 大 于 或 等 于 4 
时 使 用 并 行 线程 《第 40 行 ) ， 人 否则 则 退化 为 传统 的 插入 排序 。 





每 次 计算 后 ， 递 减 h 的 值 〈 第 58 行 ) 。 


5.9 ”并行 算法 : 矩阵 乘法 


我 在 第 一 章 中 已 经 所 到 ，Linus 认 为 并 行程 序 目 前 只 有 在 服务 端 程 
序 和 图 像 处 理 领 域 有 发 展 的 空间 。 且 不 论 这 种 说 法 是 否 正 确 ， 但 从 中 也 
可 以 看 出 并 发 对 于 这 两 个 应 用 领域 的 重要 性 。 而 对 于 图 像 处 理 来 说 ， 和 矩 
阵 运 行 是 其 中 必 不 可 少 的 重要 数学 方法 。 当 然 ， 除 了 图 像 处 理 ， 和 矩阵 运 
算 在 神经 网 络 、 模 式 识别 等 领域 也 有 着 广泛 的 用 途 。 在 这 里 ， 我 将 向 大 
家 介绍 矩阵 运算 的 典型 代表 一 一 矩阵 乘法 的 并 行 化 实现 。 























在 矩阵 乘法 中 ， 第 一 个 矩阵 的 列 数 和 第 二 个 矩阵 的 行 数 必须 是 相同 
的 。 如 图 5.16 所 示 ， 和 矩阵 A 和 和 矩阵 B 相 乘 ， 其 中 矩阵 A 为 4 行 2 列 ， 算 阵 B 
为 2 行 4 列 ， 它 们 相 乘 后 ， 得 到 的 是 4 行 4 列 的 窍 阵 ， 并 且 新 矩阵 中 每 一 个 
元 素 为 矩阵 A 和 B 对 应 行列 的 乘积 求 和 。 





图 5. 16 se RTE EA 





如 末 需 要 进行 并 行 计算 ， 一 种 简单 的 集 略 是 可 以 将 A 和 矩阵 进行 水 平 


分 割 ， 得 到 子 矩 阵 A1 和 A2，B 和 矩阵 进行 垂直 分 割 ， 得 到 子 矩 阵 B1 和 

B2。 此 时 ， 我 们 只 要 分 别 计 算 这 些 子 窍 阵 的 乘积 ， 将 结果 进行 拼接 ， 就 
能 得 到 原始 矩阵 A 和 B 的 乘积 。 如 图 5.17 所 示 ， 展 示 了 这 种 并 行 计 算 的 策 
HE o 


| B | 8 
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当然 ， 这 个 过 程 是 可 以 反复 进行 的 。 为 了 计算 Al*B1， 我 们 还 可 以 
进一步 将 A1 和 B1 进 行 分 解 ， 直 到 我 们 认为 子 和 矩阵 的 大 小 已 经 在 可 接受 
ya H A 





这 里 ， 我 们 使 用 ForkJoin 框 架 来 实现 这 个 并 行窃 阵 相 乘 的 想法 。 为 
了 方便 矩阵 计算 ， 我 们 使 用 jMatrices 开 源 软件 ， 作 为 矩阵 计算 的 工具 。 
其 中 ， 使 用 的 主要 API 如 下 : 


e Matrix: 代表 一 个 矩阵 

e MatrixOperator.multiply(Matrix, Matrix): %#P REIH 

e Matrix.row(): 获得 矩阵 的 行 数 

e Matrix.getSubMatrix(): 获得 矩阵 的 子 和 矩阵 

e MatrixOperator.horizontalConcatenation(Matrix,Matrix): 将 两 个 算 


阵 进行 水 平 连接 
e MatrixOperator.verticalConcatenation(Matrix,Matrix): 将 两 个 矩阵 
进行 垂直 连接 
为 了 计算 矩阵 乘法 ， 定 义 一 个 任务 类 MatrixMulTask。 它 会 进行 矩 
阵 相 乘 的 计算 ， 如 条 输入 矩阵 的 粒度 比较 大 ， 则 会 再 次 进行 任务 分 解 : 


01 public class MatrixMulTask extends RecursiveTask<Matrix> { 


02 Matrix m1; 

03 Matrix m2; 

04 String pos; 

05 

06 public MatrixMulTask(Matrix m1, Matrix m2, String pos) { 
07 this.mi = m1; 

08 this.m2 = m2; 

09 this.pos = pos; 

10 } 

11 

12 @Override 

13 protected Matrix compute() { 

14 //System.out.printiln(Thread.currentThread().getId()+": 


getName() + " is start"); 


15 if (mi.rows() <= PMatrixMul.granularity || m2.cols() - 
16 Matrix mRe = MatrixOperator.multiply(mi, m2); 

17 return mRe; 

18 } else { 





19 // 如 果 不 是 ， 那 么 继续 分 割 矩阵 


20 
all 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 
32 
33 
34 
35 
36 
37 
38 
39 
40 
41 
42 
43 
44 
45 
46 


int rows; 

rows = m1.rows(); 

// Fe HEH FE MB IE] 

Matrix m11 = mi.getSubMatrix(1, 1, rows / 2, mi.co 








Matrix m12 = mi.getSubMatrix(rows / 2 + 1, 1, mi.r 
// 右 乘 矩阵 纵向 分 割 
Matrix m21 = m2.getSubMatrix(1, 1, m2.rows(), m2.c 


Matrix m22 = m2.getSubMatrix(1, m2.cols() / 2 + 1, 


ArrayList<MatrixMulTask> subTasks = new ArrayList 
MatrixMulTask tmp = null; 
tmp = new MatrixMulTask(m1i1, m21, "m1"); 
subTasks.add(tmp); 
tmp = new MatrixMulTask(m11, m22, "m2"); 
subTasks.add(tmp); 
tmp = new MatrixMulTask(m12, m21, "m3"); 
subTasks.add(tmp); 
tmp = new MatrixMulTask(m12, m22, "m4"); 
subTasks.add(tmp); 
for (MatrixMulTask t : subTasks) { 
t.fork(); 
} 
Map<String, Matrix> matrixMap = new HashMap<Stri 
for (MatrixMulTask t : subTasks) { 
matrixMap.put(t.pos, t.join()); 
} 


Matrix tmp1 = MatrixOperator.horizontalConcatenati 


matrixMap.get("m2")); 
47 Matrix tmp2 = MatrixOperator.horizontalConcatenati 


matrixMap.get("m4")); 


48 Matrix reM = MatrixOperator.verticalConcatenation( 
49 return reM; 

50 } 

51 } 

52 } 


MatrixMulTask 类 由 三 个 参数 构成 ， 分 别 是 需要 计算 的 矩阵 双方 ， 
以 及 计算 结果 位 于 父 矩 阵 相 乘 结果 中 的 位 置 ， 如 图 5.18 所 示 。 
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MatrixMulTask F ff) 5 nE Em All 22 AN EA FE A FEE, pos 
表示 这 个 乘积 结果 在 父 矩 阵 相 乘 结果 中 所 处 的 位 置 ， 有 ml1、m2、m3 和 
m4 等 四 种 。 代 码 第 23 一 27 行 先 对 矩阵 进行 分 割 ， 分 割 后 得 到 ml1、 
m12、m21 和 m22 等 四 个 和 矩阵， 并 将 它们 按照 如 图 5.18 所 示 的 规则 进行 子 





任务 的 创建 。 在 第 39 一 41 行 ， 计 算 这 些 子 任务 。 在 子 任务 返回 后 ， 在 第 
42 一 48 行 将 返回 的 四 个 矩阵 m1、m2、m3 和 m4 拼 接 成 新 的 矩阵 作为 最 终 
结果 。 





如 琳 窍 阵 的 粒度 足够 小 就 直接 进行 运算 而 不 进行 分 解 〈 第 16 行 )。 





使 用 这 个 任务 类 可 以 很 容易 地 进行 矩阵 并 行 运算 ， 下 面 是 使 用 方 
法 : 
01 public static final int granularity=3; 


02 public static void main(String[] args) throws InterruptedExcep 


i 

03 ForkJoinPool forkJoinPool = new ForkJoinPool(); 

04 Matrix mi=MatrixFactory.getRandomIntMatrix(300, 300, null) 
05 Matrix m2=MatrixFactory.getRandomIntMatrix(300, 300, null) 
06 MatrixMulTask task=new MatrixMulTask(m1,m2,null); 

07 ForkJoinTask<Matrix> result = forkJoinPool.submit(task); 
08 Matrix pr=result.get(); 

09 System.out.printin(pr); 

10 } 
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任务 MatrixMulTask 并 将 其 提交 给 ForkJoinPool 线 程 池 。 第 8 行 执 行 
ForkJoinTask.get() 方 法 等 待 并 获得 最 终结 果 。 





5.10 HERE SAE: 网 络 
NIO 


Java NIO 是 New IO 的 简称 ， 它 是 一 种 可 以 替代 Java IO 的 一 套 新 的 IO 
机 制 。 它 提供 了 一 套 不 同 于 Java 标 准 IO 的 操作 机 制 。 严 格 来 说 ，NIO 与 
并 发 并 无 直接 的 关系 。 但 是 ， 使 用 NIO 技 术 可 以 大 大 提高 线程 的 使 用 效 
率 。 





Java NIO 中 涉及 的 基础 内 容 有 通道 CChannel) 和 缓冲 区 
(Buffer) 、 文 件 IO 和 网 络 IO。 有 关 通 道 、 绥 冲 区 以 及 文件 IO 在 这 里 不 
打算 进行 详细 的 介绍 ， 大 家 可 以 参考 本 章 的 参考 文献 。 在 这 里 ， 我 想 多 
花 一 点 时 间 详 细 介 绍 一 下 有 关 网 络 IO 的 内 容 。 





对 于 标准 的 网 络 IO 来 说 ， 我 们 会 使 用 Socket 进 行 网 络 的 读 写 。 为 了 
让 服务 器 可 以 文 持 更 多 的 客户 疹 连 接 ， 通 常 的 做 法 是 为 每 一 个 客户 器 连 
接 开 局 一 个 线程 。 让 我 们 先 回 顾 一 下 这 方面 的 内 容 。 


5.10.1 基于 Socket 的 服务 端的 多 线程 
模式 


这 里 ， 我 以 一 个 简单 的 Echo 服 务 器 为 例 。 对 于 Echo 服 务 器 ， 它 会 读 
取 客 户 端的 一 个 输入 ， 并 将 这 个 输入 原封 不 动 地 返回 给 客户 端 。 这 看 起 
来 很 简单 ， 但 是 麻雀 虽 小 五 脏 俱 全 。 为 了 完成 这 个 功能 ， 服 务 器 还 是 需 
要 有 一 套 完 整 的 Socket 处 理 机 制 。 因 此 ， 这 个 Echo 服 务 占 非常 适合 来 进 


行 学 习 。 实 际 上 ， 我 认为 任何 业务 逻辑 简单 的 系统 都 很 适合 学 习 ， 大 家 
不 用 为 了 去 理解 业务 上 复杂 的 功能 而 忽略 了 系统 的 重点 。 


服务 端 使 用 多 线程 进行 处 理 时 的 结构 示意 图 ， 如 图 5.19 所 示 。 








图 5.19 ”多 线程 的 服务 端 


服务 融会 为 每 一 个 客户 端 连接 月 用 一 个 线程 ， 这 个 新 的 线程 将 全 心 
全 意 为 这 个 客户 端 服务 。 同 时 ， 为 了 接受 客户 端 连接 ， 服 务 器 还 会 额外 
使 用 一 个 派发 线程 。 


下 面 的 代码 实现 了 这 个 服务 右 : 


01 public class MultiThreadEchoServer { 


02 private static ExecutorService tp=Executors.newCachedThre 
03 static class HandleMsg implements Runnable{ 

04 Socket clientSocket; 

05 public HandleMsg(Socket clientSocket) { 

06 this.clientSocket=clientSocket; 

07 } 


09 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 
32 
33 
34 
35 


public void run(){ 


BufferedReader is =null; 


PrintWriter os = null; 


try { 


new BufferedReader(new InputStreamReader (clientSo 
os = new PrintWriter(clientSocket.getOutputStr 


// 从 InputStream 当 中 读 取 客户 端 所 发 送 的 数据 


String inputLine = null; 


long b=System.currentTimeMillis(); 


while ((inputLine = is.readLine()) 


os.println(inputLine) ; 


t 


long e=System.currentTimeMillis(); 


System.out.printin("spend:"+(e-b)+"ms"); 


} catch (IOException e) { 
e.printStackTrace(); 
}finally{ 
try { 
if(is!=null)is.close(); 
if(os!=null)os.close(); 
clientSocket.close(); 
} catch (IOException e) { 


e.printStackTrace(); 


36 } 


37 public static void main(String args[]) { 

38 ServerSocket echoServer = null; 

39 Socket clientSocket = null; 

40 try { 

41 echoServer = new ServerSocket (8000) ; 

42 } catch (IOException e) { 

43 System.out.printlin(e); 

44 } 

45 while (true) { 

46 try { 

47 clientSocket = echoServer.accept(); 

48 System.out.println(clientSocket.getRemoteSocke 
49 tp.execute(new HandleMsg(clientSocket )); 
50 } catch (IOException e) { 

51 System.out.println(e); 

52 } 

53 } 

54 } 

55 } 


第 2 行 ， 我 们 使 用 了 一 个 线程 池 来 处 理 每 一 个 客户 端 连接 。 第 3 一 33 
行 ， 定 义 了 HandleMsg 线 程 ， 它 由 一 个 客户 端 Socket 构 造 而 成 ， 它 的 任 
务 是 谈 取 这 个 Socket 的 内 容 并 将 其 进行 返回 ， 返 回 成 功 后 ， 任 务 完 成 ， 
客户 端 Soceket 束 被 正常 关闭 。 其 中 第 23 行 ， 统 计 并 输出 了 服务 端 线程 处 
理 一 次 客户 端 请 求 所 花费 的 时 间 〈 包 括 读 取 数 据 和 回 写 数据 的 时 间 ) 。 
主线 程 main 的 主要 作用 是 在 8000 端 口上 进行 等 待 。 一 旦 有 新 的 客户 端 连 








接 ， 它 就 根据 这 个 连接 创建 HandleMsg 线 程 进行 处 理 《〈 第 47 一 49 行 ) 。 


这 就 是 一 个 文 持 多 线程 的 服务 端的 核心 内 容 。 它 的 特点 是 ， 在 相同 
可 文 持 的 线程 范围 内 ， 可 以 尽量 多 地 支持 客户 端的 数量 ， 同 时 和 单线 程 
服务 器 相 比 ， 它 也 可 以 更 好 地 使 用 多 核 CPU。 





为 了 方便 大 家 学 习 ， 这 里 再 给 出 一 个 客户 端的 参考 实现 : 


01 public static void main(String[] args) throws IOException { 


02 Socket client = null; 

03 PrintWriter writer = null; 

04 BufferedReader reader = null; 

05 try { 

06 client = new Socket(); 

07 client.connect(new InetSocketAddress("localhost", 8000 
08 writer = new PrintWriter(client.getOutputStream(), tru 
09 writer.printin("Hello!"); 

10 writer.flush(); 

11 

12 reader = new BufferedReader (new InputStreamReader(clie 
13 System.out.println("from server: " + reader.readLine() 
14 } catch (UnknownHostException e) { 

15 e.printStackTrace(); 

16 } catch (IOException e) { 

17 e.printStackTrace(); 

18 } finally { 

19 if (writer != null) 


20 writer.close(); 


21 if (reader != null) 


22 reader.close(); 
23 if (client != null) 
24 client.close(); 
25 } 

26 } 


上 述 代码 在 第 7 行 ， 连 接 了 服务 器 的 8000 端 口 ， 并 发 送 字符 串 。 接 
独 在 第 12 行 ， 读 取 服 务 器 的 返回 信息 并 进行 输出 。 











可 以 说 ， 这 种 多 线程 的 服务 器 开发 模式 是 极其 常用 的 。 对 于 绝 大 多 
数 应 用 来 说 ， 这 种 模式 可 以 很 好 地 工作 。 但 是 ， 如 果 你 想 让 你 的 程序 工 


作 得 更 加 有 效 ， 就 必须 知道 这 种 模式 的 一 个 重大 弱点 一 一 那 就 是 它 倾 问 
于 让 CPU 进行 IO 等 待 。 为 了 理解 这 一 点 ， 让 我 们 看 一 下 下 面 这 个 比较 极 
端的 例子 : 


01 public class HeavySocketClient { 


02 private static ExecutorService tp=Executors.newCachedThre 
03 private static final int sleep_time=1000*1000*1000; 

04 public static class EchoClient implements Runnable{ 

05 public void run(){ 

06 Socket client = null; 

07 PrintWriter writer = null; 

08 BufferedReader reader = null; 

09 try { 

10 client = new Socket(); 

11 client.connect(new InetSocketAddress("localhos 


12 writer = new PrintWriter(client.getOutputStrea 


13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 
32 
33 
34 
35 
36 
37 
38 
39 


writer.print("H"); 
LockSupport.parkNanos(sleep_time); 
writer.print("e"); 
LockSupport.parkNanos(sleep_time); 
writer.print("1"); 
LockSupport.parkNanos(sleep_time); 
writer.print("1"); 
LockSupport.parkNanos(sleep_time); 
writer.print("o"); 
LockSupport.parkNanos(sleep_time); 
writer.print("!"); 
LockSupport.parkNanos(sleep_time); 
writer.printlin(); 


writer.flush(); 


reader = new BufferedReader (new InputStreamReade 
System.out.println("from server: " + reader.re 

catch (UnknownHostException e) { 
e.printStackTrace(); 

catch (IOException e) { 


e.printStackTrace(); 


finally { 
try { 
if (writer != null) 
writer.close(); 
if (reader != null) 


reader.close(); 


40 if (client != null) 


41 client.close(); 
42 } catch (IOException e) { 
43 } 

44 } 

45 } 

46 } 

47 public static void main(String[] args) throws IOException 
48 EchoClient ec=new EchoClient(); 
49 for(int i=0;i<10;i++) 

50 tp.execute(ec); 

51 } 

52 } 


上 述 代码 定义 了 一 个 新 的 客户 端 ， 它 会 进行 10 次 请 求 〈 第 49 一 50 行 
开启 10 个 线程 ) 。 每 一 次 请 求 都 会 访问 8000 端 口 。 连 接 成 功 后 ， 会 癌 服 
务 器 输出 “Hello!”* 字 符 串 (第 13~~26 行 )， 但 是 在 这 一 次 交互 中 ， 客 户 
端 会 慢 慢 地 进行 输出 ， 每 次 只 输出 一 个 字符 ， 之 后 进行 1 秒 的 等 待 。 因 
此 ， 整 个 过 程 会 持续 6 秒 。 





开局 多 线程 池 的 服务 需 和 上 述 客户 端 。 服 务 器 端的 部 分 输出 如 下 : 


spend: 6000ms 
spend: 6000ms 
spend: 6000ms 
spend: 6001ms 
spend: 6002ms 
spend: 6002ms 


spend:6002ms 
spend: 6002ms 
spend: 6003ms 
spend: 6003ms 





可 以 看 到 ， 对 于 服务 端 来 说 ， 每 一 个 请 求 的 处 理 时 间 都 在 6 秒 无 
右 。 这 很 容易 理解 ， 因 为 服务 器 要 先 读 入 客户 端的 输入 ， 而 客户 站 缓慢 
的 处 理 速度 《当然 也 可 能 是 一 个 拥塞 的 网 络 环境 ) 使 得 服务 器 花费 了 不 


少 等 待 时 间 。 


我 们 可 以 试想 一 人 下， 如 宋 服 务 器 要 处 理 大 量 的 请 求 连接 ， 每 个 请 求 
如 果 都 像 这 样 拖 慢 了 服务 器 的 处 理 速度 ， 那 么 服务 端 能 够 处 理 的 并 发 数 
量 就 会 大 幅度 减少 。 反 之 ， 如 果 服 务 占 每 次 都 能 很 快 地 处 理 一 次 请 求 ， 
那么 相对 的 ， 它 的 并 友人 能 力 束 能 上 升 。 

在 这 个 案例 中 ， 服 务 器 处 理 请 求 之 所 以 慢 ， 并 不 是 因为 在 服务 端 有 
多 少 繁 重 的 任务 ， 而 仅仅 是 因为 服务 线程 在 等 待 IO 而 已 。 让 高 速 运转 的 
CPU 去 等 待 极其 低 效 的 网 络 IO 是 非常 不 合算 的 行为 。 那 么 ， 我 们 是 不 是 
可 以 想 一 个 方法 ， 将 网 络 IO 的 等 待 时 间 从 线程 中 分 离 出 来 呢 ? 


5.10.2 ”使 用 NIO 进 行 网 络 编程 


使 用 Java 的 NIO 就 可 以 将 上 面 的 网 络 IO 等 待 时 间 从 业务 处 理 线程 中 
抽取 出 来 。 那 么 NIO 是 什么 ， 它 又 是 如 何 工 作 的 呢 ? 





要 了 解 NIO， 我 们 首先 需要 知道 在 NIO 中 的 一 个 关键 组 件 
Channel 〈 通 道 ) 。Channel 有 点 类 似 于 流 ， 一 个 Channel 可 以 和 文件 或 者 


网 络 Socket 对 应 。 如 果 Channel 对 应 着 一 个 Soceket， 那 么 往 这 个 Channel 
中 写 数据 ， 就 等 同 于 同 Socket 中 写 入 数据 。 


和 Channel 一 起 使 用 的 男 外 一 个 重要 组 件 就 是 Buffer。 大 家 可 以 简单 
地 把 Buffer 理 解 成 一 个 内 存 区 域 或 者 byte 数 组 。 数 据 需 要 包装 成 Buffer 的 
形式 才能 和 Channel 交 互 〈 写 入 或 者 读 取 ) 。 


另外 一 个 与 Channel 密 切 相 关 的 是 Selector (选择 器 ) 。 在 Channel 的 
众多 实现 中 ， 有 一 个 SelectableChannel 实 现 ， 表 示 可 被 选择 的 通道 。 任 
何 一 个 SelectableChannel 都 可 以 将 自己 注册 到 一 个 Selector 中 。 这 样 ， 这 
个 Channel 就 能 被 Selector 所 管理 。 而 一 个 Selector 可 以 管理 多 个 
SelectableChannel。 当 SelectableChannel 的 数据 准备 好 时 ，Selector 就 会 接 
到 通知 ， 得 到 那些 已 经 准备 好 的 数据 。 而 SocketChannel 束 是 
SelectableChannel 的 一 种 。 因 此 ， 它 们 构成 了 如 图 5.20 所 示 的 结构 。 
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图 5. 20 Selector 4eChannel 


大 家 可 以 看 到 ， 一 个 Selector 可 以 由 一 个 线程 进行 管理 ， 而 一 个 
SocketChannel 则 可 以 表示 一 个 客户 端 连接 ， 因 此 这 就 构 成 由 一 个 或 者 极 
少数 线程 ， 来 处 理 大 量 客户 端 连接 的 结构 。 当 与 客户 端 连 接 的 数据 没有 
准备 好 时 ，Selector 会 处 于 等 竺 状态 〈 不 过 乎 好， 用 于 管理 Selector 的 线 
程 数 是 极 少量 的 ) ， 而 一 旦 有 任何 一 个 SocketChannel 准 备 好 了 数据 ， 











Selector 束 能 立即 得 到 通知 ， 获 取 数 据 进行 处 理 。 





下 面 就 让 我 们 用 NIO 来 重新 构造 这 个 多 线程 的 Echo 服务 器 吧 ! 
首先 ， 我 们 需要 定义 一 个 Selector 和 线程 池 : 


private Selector selector; 


private ExecutorService tp=Executors.newCachedThreadPool(); 


其 中 ，selector 用 于 处 理 所 有 的 网 络 连接 。 线 程 池 tp 用 于 对 每 一 个 客 
户 端 进行 相应 的 处 理 ， 每 一 个 请 求 都 会 委托 给 线程 池 中 的 线程 进行 实际 
的 处 理 。 

为 了 能 够 统计 服务 器 线程 在 一 个 客户 端 上 人 花费 了 多 少时 间 ， 这 里 还 
需要 定义 一 个 与 时 间 统 计 有 关 的 类 : 


public static Map<Socket,Long> time_stat=new HashMap<Socket, Lon 


它 用 于 统计 在 某 一 个 Socket 上 花费 的 时 间 ，time_stat 的 key 为 
Socket，value 为 时 间 礁 (可 以 记录 处 理 开 始 时 间 〉。 





下 面 就 可 以 来 看 一 下 NIO 服 务 器 的 核心 代码 ， 下 面 的 startServer() 方 
法 用 于 启动 NIO Server: 


01 private void startServer() throws Exception { 


02 selector = SelectorProvider.provider().openSelector(); 
03 ServerSocketChannel ssc = ServerSocketChannel.open(); 
04 ssc.configureBlocking(false) ; 

05 


06 InetSocketAddress isa = new InetSocketAddress(InetAddress. 


07 
08 
09 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 
32 
33 


InetSocketAddress isa = new InetSocketAddress(8000) ; 


ssc.socket().bind(isa); 


SelectionkKey acceptKey = ssc.register(selector, Selectionk 


BOM or ye. 
selector.select(); 
Set readyKeys = selector.selectedKeys()/; 
Iterator i = readyKeys.iterator(); 
long e=0; 
while (1.hasNext()) { 
SelectionKkKey sk = (SelectionKey) i.next(); 


i.remove(); 


if (sk.isAcceptable()) { 
doAccept(sk); 


} 
else if (sk.isValid() && sk.isReadable()) { 


if(!time_stat.containsKey(((SocketChannel)sk.c 


time_stat.put(((SocketChannel)sk.channel() 


System.currentTimeMillis()); 
doRead(sk); 
} 
else if (sk.isValid() && sk.isWritable()) { 
doWrite(sk); 


e=System.currentTimeMillis(); 


long b=time_stat.remove(((SocketChannel)sk. 


cha 


34 System.out.println("spend:"+(e-b)+"ms"); 


上 述 代 码 第 2 行 ， 通 过 工矿 方法 获得 一 个 Selector 对 象 的 实例 。 第 3 
行 ， 获 得 表示 服务 端的 SocketChannel 实 例 。 第 4 行 ， 将 这 个 
SocketChannel 设 置 为 非 阻塞 模式 。 实 际 上 ，Channel 也 可 以 像 传统 的 
Socket 那 样 按照 阻塞 的 方式 工作 。 但 在 这 里 ， 更 倾向 于 让 其 工作 在 非 阻 
塞 模式 ， 在 这 种 模式 下 ， 我 们 才 可 以 癌 Channel 注 册 感 兴趣 的 事件 ， 并 
且 在 数据 准备 好 时 ， 得 到 必要 的 通知 。 接 着 ， 在 第 6~8 行 进行 端口 绑 
定 ， 将 这 个 Channel 绑 定 在 8000 端 口 。 





在 第 10 行 ， 将 这 个 ServerSocketChannel 绑 定 到 Selector 上 ， 并 注册 它 
感 兴趣 的 时 间 为 Accept。 这 样 ，Selector 束 能 为 这 个 Channel 服 务 了 。 当 
Selector 发 现 ServerSocketChannel/ 有 新 的 客户 端 连接 时 ， 就 会 通知 
ServerSocketChannel 进 行 处 理 。 方 法 register0 的 返回 值 是 一 个 
SelectionKey，SelectionKey 表 示 一 对 Selector 和 Channel 的 关系 。 当 
Channel 注 册 到 Selector 上 时 ， 就 相当 于 确立 了 两 者 的 服务 关系 ， 那 么 
SelectionKey 就 是 这 个 契约 。 当 Selector 或 者 Channel 被 关闭 时 ， 它 们 对 应 
的 SelectionKey 就 会 失效 。 


第 12 一 37 行 是 一 个 无 穷 循 环 ， 它 的 主要 任务 就 是 等 待 -分 发 网 络 消 


CI 


第 13 行 的 select(0 方 法 是 一 个 阻塞 方法 。 如 采 当 前 没有 任何 数据 准备 
好 ， 它 就 会 等 等。 一 旦 有 数据 可 读 ， 它 就 会 运 回 。 它 的 返回 值 是 已 经 准 


备 就 绪 的 SelectionKey 的 数量 。 这 里 简单 地 将 其 忽略 。 


第 14 行 获取 那些 准备 好 的 SelectionKey。 因 为 Selector 同 时 为 多 个 
Channel 服 务 ， 因 此 已 经 准备 就 绪 的 Channel 束 有 可 能 是 多 个 。 所 以 ， 这 
里 得 到 的 自然 是 一 个 集合 。 得 到 这 个 就 绪 集 合 后 ， 剩 下 的 就 是 过 历 这 个 
集合 ， 挨 个 处 理 所 有 的 Channel 数 据 。 


第 15 行 得 到 这 个 集合 的 迭代 器 。 第 17 行 使 用 达 代 器 授 历 整 个 集合 。 
第 18 行 根据 迭代 右 获 得 一 个 集合 内 的 SelectionKey 实 例 。 


第 19 行 将 这 个 元 素 移 除 ! 注意 ， 这 个 非常 重要 ， 人 否则 就 会 重复 处 理 
相同 的 SelectionKey。 当 你 处 理 完 一 个 SelectionKey 后 ， 务 必 将 其 从 集合 
内 删除 。 


第 21 行 判断 当前 SelectionKey 所 代表 的 Channel 是 否 在 Acceptable 状 
态 ， 如 果 是 ， 就 进行 客户 病 的 接收 (执行 doAccept0) 方 法 ) 。 


第 24 行 判断 Channel 是 否 已 经 可 以 读 了 ， 如 果 是 就 进行 读 取 
(doRead() 方 法 ) 。 这 里 为 了 统计 系统 处 理 每 一 个 连接 的 时 间 ， 在 第 25 
一 27 行 记录 了 在 读 取 数据 之 前 的 一 个 时 间 戳 。 





第 30 行 判断 通道 是 否 准备 好 进行 写 。 如 果 是 就 进行 写 入 (doWirite() 
WME) ， 同 时 在 写 入 完成 后 ， 根 据 读 取 前 的 时 间 稚 ， 输 出 处 理 这 个 
Socket 连 接 的 耗 时 。 





在 了 解 服务 端的 整体 框架 后 ， 下 面 让 我 们 从 细节 着手 ， 学 习 一 下 几 
个 主要 方法 的 内 部 实现 。 首 先是 doAccept(0) 方 法 ， 它 与 客户 端 建立 连 
接 : 





01 private void doAccept(Selectionkey sk) { 


02 ServerSocketChannel server = (ServerSocketChannel) sk.chan 


03 SocketChannel clientChannel; 

04 try { 

05 clientChannel = server.accept(); 

06 clientChannel.configureBlocking( false); 

07 

08 // Register this channel for reading. 

09 SelectionKey clientKey = clientChannel.register(select 
10 // Allocate an EchoClient instance and attach it to th 
11 EchoClient echoClient = new EchoClient(); 

12 clientKey.attach(echoClient); 

13 

14 InetAddress clientAddress = clientChannel.socket().get 
15 System.out.println("Accepted connection from " + clien 
16 } catch (Exception e) { 

17 System.out.println("Failed to accept new client."); 

18 e.printStackTrace(); 

19 } 

20 } 


和 Socket 编 程 很 类 似 ， 当 有 一 个 新 的 客户 端 连接 接 入 时 ， 就 会 有 一 
个 新 的 Channel 产 生 代表 这 个 连接 。 上 述 代 人 码 第 5 行 ， 生 成 的 
clientChannel 就 表示 和 客户 病 通 信 的 通道 。 第 6 行 ， 将 这 个 Channel 配 置 
为 非 阻 塞 模式 ， 也 就 是 要 求 系统 在 准备 好 IO 后 ， 再 通知 我 们 的 线程 来 读 
取 或 者 写 入 。 





第 9 行 很 关键 ， 它 将 新 生成 的 Channel 注 册 到 selector 选 择 器 上 ， 并 告 


诉 Selector， 我 现在 对 读 (OP READ) 操作 感 兴趣 。 这 样 ， 当 Selector 发 
现 这 个 Channel 已 经 准备 好 读 时 ， 就 能 给 线程 一 个 通知 。 


第 11 行 新 建 一 个 对 象 实例 ， 一 个 EchoClient 实 例 代 表 一 个 客户 端 。 
在 第 12 行 ， RIETER im KANE IMHE, a | 
SelectionKey 上 。 这 样 在 整个 连接 的 处 理 过 程 中 ， 我 们 都 可 以 共享 这 
EchoClient 实 例 。 


EchoClient 的 定义 很 简单 ， 它 封装 了 一 个 队列 ， 保 存在 需要 回复 给 
这 个 客户 端的 所 有 信息 ， 这 样 ， 再 进行 回复 时 ， 只 要 从 outq 对 象 中 弹出 
元 素 即 可 。 


class EchoClient { 

private LinkedList<ByteBuffer> outq; 

EchoClient() { 
outq = new LinkedList<ByteBuffer>(); 

J 

public LinkedList<ByteBuffer> getOutputQueue() { 
return outq; 

} 

public void enqueue(ByteBuffer bb) { 
outq.addFirst(bb); 


下 面 来 看 一 下 另外 一 个 重要 的 方法 doRead0。 当 Channel 可 以 读 取 
时 ，doRead() 方 法 就 会 被 调用 。 


01 private void doRead(Selectionkey sk) { 


02 SocketChannel channel = (SocketChannel) sk.channel(); 
03 ByteBuffer bb = ByteBuffer.allocate(8192); 

04 int len; 

05 

06 try { 

07 len = channel.read(bb); 

08 if (len < 0) { 

09 disconnect(sk); 

10 return; 

11 } 

12 } catch (Exception e) { 

13 System.out.println("Failed to read from client."); 
14 e.printStackTrace(); 

15 disconnect(sk); 

16 return; 

17 } 

18 

19 bb.flip(); 

20 tp.execute(new HandleMsg(sk,bb)); 

21 } 


方法 doRead() 接 收 一 个 SelectionKey 参 数 ， 通 过 这 个 SelectionKey 可 
以 得 到 当前 的 客户 端 Channel 〈 第 2 行 ) 。 在 这 里 ， 我 们 准备 8K 的 缓冲 区 
读 取 数据 ， 所 有 读 取 的 数据 存放 在 变量 bb 中 (第 7 行 )。 读 取 完 成 后 ， 
重 置 缓冲 区 ， 为 数据 处 理 做 准备 《第 19 行 ) 。 








在 这 个 示例 中 ， 我 们 对 数据 的 处 理 很 简单 。 但 是 为 了 模拟 复杂 的 场 
景 ， 还 是 使 用 了 线程 池 进 行 数 据 处 理 〈 第 20 行 ) 。 这 样 ， 如 果 数 据 处 理 
很 复杂 ， 就 能 在 单独 的 线程 中 进行 ， 而 不 用 阻 蹇 任务 派发 线程 。 








HandleMsg 的 实现 也 很 简单 : 


01 class HandleMsg implements Runnable{ 


02 SelectionKey sk; 

03 ByteBuffer bb; 

04 public HandleMsg(SelectionKey sk,ByteBuffer bb){ 

05 this.sk=sk; 

06 this .bb=bb; 

07 } 

08 @Override 

09 public void run() { 

10 EchoClient echoClient = (EchoClient) sk.attachment(); 
11 echoClient.enqueue(bb); 

12 sk.interestOps(SelectionKey.OP_READ | SelectionKey.OP_! 
13 // 强 迫 selector 立 即 返回 

14 selector.wakeup(); 

15 } 

16 } 


上 述 代 码 ， 简 单 地 将 接收 到 的 数据 压 入 EchocClient 的 队列 《第 11 
行 )。 如 果 需 要 处 理 业 务 逻 辑 ， 就 可 以 在 这 里 进行 处 理 。 


在 数据 处 理 完 成 后 ， 就 可 以 准备 将 结果 回 写 到 客户 端 ， 因 此 ， 重 新 
注册 感 兴趣 的 消息 事件 ， 将 写 操 作 (OP_ WRITE ) 也 作为 感 兴趣 的 事件 





进行 提交 【第 12 行 ) 。 这 样 在 通道 准备 好 写 入 时 ， 束 能 通知 线程 。 
写 入 操作 使 用 doWriteO 函 数 实现 : 


01 private void dowrite(Selectionkey sk) { 


02 SocketChannel channel = (SocketChannel) sk.channel(); 
03 EchoClient echoClient = (EchoClient) sk.attachment(); 
04 LinkedList<ByteBuffer> outq = echoClient.getOutputQueue( ) 
05 

06 ByteBuffer bb = outq.getLast(); 

07 try { 

08 int len = channel.write(bb); 

09 if (len == -1) { 

10 disconnect(sk); 

11 return; 

12 } 

13 

14 if (bb.remaining() == 0) { 

15 // The buffer was completely written, remove it. 
16 outq.removeLast(); 

17 } 

18 } catch (Exception e) { 

19 System.out.printin("Failed to write to client."); 
20 e.printStackTrace(); 

21 disconnect(sk); 

22 } 


23 


24 if (outq.size() == 0) { 


25 sk.interestOps(SelectionKey.OP_READ) ; 


函数 doWwrite0) 也 接收 一 个 SelectionKey， 当 然 针 对 一 个 客户 端 来 
说 ， 这 个 SelectionKey 实 例 和 doRead() 拿 到 的 SelectionKey 是 同一 个 。 
此 ， 通 过 SelectionKey 我 们 就 可 以 在 这 两 个 操作 中 共享 EchoClient 实 例 。 
上 述 代 码 第 3 一 4 行 ， 我 们 取得 EchoClient 实 例 以 及 它 的 发 送 内容 列 表 。 
第 6 行 ， 获 得 列表 顶部 元 素 ， 准 备 写 回 客户 端 。 第 8 行进 行 写 回 操作 。 如 
果 全 部 发 送 完 成 ， 则 移 除 这 个 缓存 对 象 〈( 第 16 行 )。 


在 doWrite0 中 最 重要 的 ， 也 是 最 容易 被 忽略 的 是 在 全 部 数据 友 送 完 
成 后 《也 就 是 outq 的 长 度 为 0) ， 需 要 将 写 事件 COP_WRITE) 从 感 兴 
趣 的 操作 中 移 除 〈 第 25 行 )。 如 果 不 这 么 做 ， 每 次 Channel 准 备 好 写 
时 ， 都 会 来 执行 doWrite() 方 法 。 而 实际 上 ， 你 叉 无 数据 可 写 ， 这 显然 是 
不 合理 的 。 因 此 ， 这 个 操作 很 重要 。 








上 面 我 们 已 经 介绍 了 主要 的 核心 代码 ， 现 在 使 用 这 个 NIO 服 务 器 来 
处 理 上 一 节 中 客户 端的 访问 。 同 样 的 ， 客 户 端 也 是 要 人 花费 将 近 6 秒 钟 ， 
才能 完成 一 次 消息 的 发 送 ， 那 使 用 NIO 技 术 后 ， 服 务 端 线程 需要 人 花费 多 
少时 间 来 处 理 这 些 请 求 呢 ? 答案 如 下 : 





spend: 2ms 
spend: 2ms 
spend: 2ms 
spend: 2ms 


spend: 3ms 


spend:3ms 
spend :0ms 
spend :0ms 
spend: 2ms 


spend: 3ms 


可 以 看 到 ， 在 使 用 NIO 技 术 后 ， 即 使 客户 端 迟 钝 或 者 出 现 了 网 络 延 
迟 等 现象 ， 并 不 会 给 服务 顺带 来 太 大 的 问题 。 


5.10.3 ”使 用 NIO 来 实现 客户 端 


在 前 面 的 案例 中 ， 我 们 使 用 Socket 编 程 来 构建 我 们 的 客户 端 ， 使 用 
NIO 来 实现 服务 端 。 实 际 上 ， 使 用 NIO 也 可 以 用 来 创建 客户 端 。 这里， 
我 们 再 演示 一 下 使 用 NIO 创 建 客户 端的 例子 。 


和 构造 服务 器 类 似 ， 核 心 的 元 素 也 是 Selector、Channel 和 
SelectionKey. 


首先 ， 我 们 需要 初始 化 Selector 和 Channel: 


01 private Selector selector; 


02 public void init(String ip, int port) throws IOException { 


03 SocketChannel channel = SocketChannel.open(); 

04 channel.configureBlocking(false) ; 

05 this.selector = SelectorProvider.provider().openSelector() 
06 channel.connect(new InetSocketAddress(ip, port)); 


07 channel.register(selector, SelectionKey.OP_CONNECT); 


08 } 


上 述 代 码 第 3 行 ， 创 建 一 个 SocketChannel 实 例 ， 并 设置 为 非 阻 塞 模 
式 。 第 5 行 创建 了 一 个 Selector。 第 6 行 ， 将 SocketChannel 绑 定 到 Socket 
上 。 但 由 于 当前 Channel 是 非 阻塞 的 ， 因 此 ，connect(0 方 法 返回 时 ， 连 接 
并 不 一 定 建 立成 功 ， 在 后 续 使 用 这 个 连接 时 ， 还 需要 使 用 
finishConnectO 再 次 确认 。 第 7 行 ， 将 这 个 Channel 和 Selector 进 行 绑 定 ， 
并 注册 了 感 兴 趣 的 事件 作为 连接 (OP_CONNECT) 。 








初始 化 完成 后 ， 就 是 程序 的 主要 执行 逻辑 : 


01 public void working() throws IOException { 








02 while (true) { 

03 if (!selector.isOpen()) 

04 break; 

05 selector.select( ); 

06 Iterator<SelectionkKey> ite = this.selector.selectedke 
07 while (ite.hasNext()) { 

08 Selectionkey key = ite.next(); 
09 ite.remove(); 

10 // 连接 事件 发 生 

11 if (key.isConnectable()) { 

12 connect (key); 

13 } else if (key.isReadable()) { 
14 read(key); 

15 } 

16 } 


i7 } 


18 } 


在 上 述 代码 中 ， 第 5 行 通过 Selector 得 到 已 经 准备 好 的 事件 。 如 果 当 
前 没有 任何 事件 准备 就 绪 ， 这 里 就 会 阻塞 。 这 里 的 整个 处 理 机 制 和 服务 
病 非 常 类 似 ， 主 要 处 理 两 个 事件 ， 首 先是 表示 连接 就 绪 的 Connct 事 件 
(由 connect() 函 数 处 理 ) 以 及 表示 通道 可 读 的 Read 事 件 〈 由 read0O 函 数 
处 理 ) 。 











函数 connectO 的 实现 如 下 : 


01 public void connect(Selectionkey key) throws IOException { 








02 SocketChannel channel = (SocketChannel) key.channel(); 

03 // 如 果 正 在 连接 ， 则 完成 连接 

04 if (channel.isConnectionPending()) { 

05 channel. finishConnect(); 

06 } 

07 channel.configureBlocking(false); 

08 channel.write(ByteBuffer.wrap(new String("hello server!\r\ 
09 .getBytes())); 

10 channel.register(this.selector, SelectionKey.OP_READ); 

11 } 


上 述 connect0) 函 数 接收 SelectionKey 作 为 其 参数 。 在 第 4 一 6 行 ， 它 首 
先 判断 是 否 连 接 已 经 建立 ， 如 果 没 有 ， 则 调用 finishConnectO 完 成 连 
接 。 建 立 连接 后 ， 同 Channel 写 入 数据 ， 并 同时 注册 读 事件 为 感 兴趣 的 
事件 (第 10 行 )。 


当 Channel 可 读 时 ， 会 执行 read0 方 法 ， 进 行 数据 读 取 ; 


01 public void read(SelectionKey key) throws IOException { 


02 
03 
04 
05 
06 
07 
08 
09 
10 
cles: 


SocketChannel channel = (SocketChannel) key.channel(); 
// BLN Bat K 
ByteBuffer buffer = ByteBuffer.allocate(100); 





channel.read(buffer); 

byte[] data = buffer.array(); 

String msg = new String(data).trim(); 
System.out.printLn(" 客 户 端 收 到 信息 : " + msg); 
channel.close(); 


key.selector().close(); 


上 述 read() 函 数 首 先 创 建 了 100 字 市 的 缓冲 区 (第 4 行 )， 接 着 从 


Channel 中 读 取 数 据 ， 并 将 其 打印 在 控制 台 上 。 最 后 ， 关 闭 Channel 和 


Selector. 


5.11 ese S AIR: AIO 


AIO 是 异步 IO 的 缩写 ， 即 Asynchronized。 虽 然 NIO 在 网 络 操作 中 ， 
提供 了 非 阻 塞 的 方法 ， 但 是 NIO 的 IO 行为 还 是 同步 的 。 对 于 NIO 来 说 ， 
我 们 的 业务 线程 是 在 IO 操作 准备 好 时 ， 得 到 通知 ， 接 着 束 由 这 个 线程 自 
行进 行 IO 操作 ，IO 操 作 本 身 还 是 同步 的 。 





但 对 于 AIO 来 说， 则 更 加 进 了 一 步 ， 它 不 是 在 IO 准备 好 时 再 通知 线 
程 ， 而 是 在 IO 操作 已 经 完成 后 ， 再 给 线程 发 出 通知 。 因 此 ，AIO 是 完 
不 会 阻塞 的 。 此 时 ， 我 们 的 业务 逻辑 将 变 成 一 个 回调 函数 ， 等 待 IO 操作 
完成 后 ， 由 系统 自动 触发 。 


下 面 ， 我 将 通过 AIO 来 实现 一 个 简单 的 EchoServer 以 及 对 应 的 客户 
Üi o 


5.11.1 AIO EchoServer 的 实现 





异步 IO 需要 使 用 异步 通道 (AsynchronousServerSocketChannel) : 


public final static int PORT = 8000; 
private AsynchronousServerSocketChannel server; 
public AIOEchoServer() throws IOException { 


server = AsynchronousServerSocketChannel.open().bind(new Inet 


上 述 代 码 绑 定 了 8000 端 口 为 服务 器 端口 ， 并 使 用 


AsynchronousServerSocketChannel 异 步 Channel 作 为 服务 器 ， 变 量 名 为 


server. 
我 们 使 用 这 个 server 来 进行 客户 端的 接收 和 处 理 : 


01 public void start() throws InterruptedException, ExecutionExce 

















02 System.out.printin("Server listen on " + PORT); 

03 // 注 册 事 件 和 事件 完成 后 的 处 理 器 

04 server.accept(null, new CompletionHandler <AsynchronousSoct 
05 final ByteBuffer buffer = ByteBuffer.allocate(1024); 
06 public void completed(AsynchronousSocketChannel result 
07 System.out.printiln(Thread.currentThread().getName( 
08 Future<Integer> writeResult=null; 

09 try { 

10 buffer.clear(); 

11 result.read(buffer).get(100, TimeUnit.SECONDS) 
12 buffer.flip(); 

13 writeResult=result.write(buffer ) ; 

14 } catch (InterruptedException | ExecutionException 
15 e.printStackTrace(); 

16 } catch (TimeoutException e) { 

17 e.printStackTrace(); 

18 } finally { 

19 try { 

20 server.accept(null, this); 

21 writeResult.get(); 


22 result.close(); 


23 } catch (Exception e) { 


24 System.out.printin(e.toString()); 


29 @Override 
30 public void failed(Throwable exc, Object attachment) { 


31 System.out.printin("failed: " + exc); 


33 3); 








上 述 定 义 的 start(0 方 法 开局 了 服务 器 。 值 得 注意 的 是 ， 这 个 方法 除 
了 第 2 行 的 打印 语句 外 ， 只 调用 了 一 个 函数 server.accept()。 之 后 ， 你 看 
到 的 那 一 大 堆 代 码 只 是 这 个 函数 的 参数 。 


AsynchronousServerSocketChannel.acceptO) 方 法 会 立即 返回 。 它 并 不 
会 真 的 去 等 待 客户 问 的 到 来 。 在 这 里 使 用 的 acceptO 方 法 的 签名 为 ; 


public final <A> void accept(A attachment, 


CompletionHandler <AsynchronousSocketChannel, ? 


它 的 第 一 个 参数 是 一 个 附件 ， 可 以 是 任意 类 型 ， 作 用 是 让 当前 线程 
和 后 续 的 回调 方法 可 以 共享 信息 ， 它 会 在 后 续 调 用 中 ， 传 递 给 handler。 
它 的 第 二 个 参数 是 CompletionHandler 接 口 。 这 个 接口 有 两 个 方法 : 


void completed(V result, A attachment); 


void failed(Throwable exc, A attachment); 
这 两 个 方法 分 别 在 异步 操作 acceptO0 成 功 或 者 失败 时 被 回调 。 


此 AsynchronousServerSocketChannel.acceptO 实 际 上 做 了 两 件 事 ， 
第 一 是 发 起 accept 请 求 ， 告 诉 系 统 可 以 开始 监听 端口 了 。 第 二 ， 注 册 
CompletionHandler 实 例 ， 告 诉 系统 ， 一 旦 有 客户 端 前 来 连接 ， 如 果 成 功 
连接 ， 就 去 执行 CompletionHandler.completed(0) 方 法 ， 如 果 连 接 失 败 ， 就 
去 执行 CompletionHandler.failed() 方 法 。 





所 以 ，server.accept() 方 法 不 会 阻 窒 ， 它 会 立即 返回 。 


下 面 ， 来 分 析 一 下 CompletionHandler.completed0 的 实现 。 当 
completed() 被 执行 时 ， 意 味 着 已 经 有 客户 并 成 功 连接 了 。 在 第 11 行 ， 使 
用 read0 方 法 读 取 客户 的 数据 。 这 里 要 注意 ， 
AsynchronousSocketChannelread(0) 方 法 也 是 异步 的 ， 换 句 话 说 它 不 会 等 
待 读 取 完成 了 再 返回 ， 而 是 立即 返回 ， 返 回 的 结果 是 一 个 Future， 因 此 
这 里 就 是 Future 模 式 的 典型 应 用 。 为 了 编程 方便 ， 我 在 这 里 直接 调用 
Future.get(0 方 法 ， 进 行 等 待 ， 将 这 个 异步 方法 变 成 了 同步 方法 。 因 此 ， 
在 第 11 行 执行 完成 后 ， 数 据 读 取 就 已 经 完成 了 。 





之 后 ， 将 数据 回 写 给 客户 端 〈 第 13 行 ) 。 这 里 调用 的 是 
AsynchronousSocketChannel.write() 方 法 。 这 个 方法 不 会 等 待 数据 全 部 写 
完 ， 也 是 立即 返回 的 。 同 样 ， 它 返回 的 也 是 Future 对 象 。 





再 之 后 ， 在 第 20 行 ， 服 务 器 进行 下 一 个 客户 端 连接 的 准备 。 同 时 关 
闭 当 前 正在 处 理 的 客户 端 连 接 。 但 在 关闭 之 前 ， 得 先 确保 之 前 的 write0) 
操作 已 经 完成 ， 因 此 ， 使 用 Future.get0 方 法 进行 等 待 〈 第 21 行 ) 。 





接 下 来 ， 我 们 只 需要 在 主 函 数 中 调用 这 个 start() 方 法 就 可 以 开局 服 
Bae I: 


01 public static void main(String args[]) throws Exception { 


02 new AIOEchoServer().start(); 
03 // 主线 程 可 以 继续 自己 的 行为 

04 while (true) { 

05 Thread.sleep(1000); 

06 } 

07 } 


上 述 代 码 第 2 行 ， 调 用 start(0 方 法 开局 服务 器 。 但 由 于 startO 方 法 里 
使 用 的 都 是 异步 方法 ， 因 此 它 会 马上 返回 ， 它 并 不 像 阻塞 方法 那样 会 进 
行 等 待 。 因 此 ， 如 果 想 让 程序 驻守 执行 ， 第 4 一 6 行 的 等 待 语句 是 必需 
的 。 人 否则 ， 在 start(O 方 法 结束 后 ， 不 等 客户 端 到 来 ， 程 序 已 经 运行 完 
成 ， 主 线程 就 将 退出 。 








5.11.2 AIO Echo 客户 端 实现 


在 服务 端的 实现 中 ， 我 们 使 用 Future.get() 方 法 将 异步 调用 转 为 了 一 
个 同步 等 每 。 在 客户 端的 实现 里 ， 我 们 将 全 部 使 用 异步 回调 实现 : 








01 public class AIOClient { 

02 public static void main(String[] args) throws Exception { 
03 final AsynchronousSocketChannel client = AsynchronousS 
04 client.connect(new InetSocketAddress("localhost", 8000), nul 


05 @Override 


06 public void completed(Void result, Object attachme 


07 client.write(ByteBuffer.wrap("Hello!".getBytes()), null, ne 


08 @Override 

09 public void completed(Integer result, Obje 
10 try { 

11 ByteBuffer buffer = ByteBuffer.all 
12 client.read(buffer, buffer,new CompletionHa 
13 @Override 

14 public void completed(Integer 
15 buffer.flip(); 

16 System.out.printin(new Str 
17 try { 

18 client.close(); 

19 } catch (IOException e) { 
20 e.printStackTrace(); 
21 } 

22 } 

23 @Override 

24 public void failed(Throwable e 
25 } 

26 +); 

27 } catch (Exception e) { 

28 e.printStackTrace(); 

29 } 

30 b 

31 @Override 


32 public void failed(Throwable exc, Object a 


34 }); 

35 } 

36 @Override 

37 public void failed(Throwable exc, Object attachmen 
38 } 

39 }); 

40 // 由 于 主线 程 马上 结束 ， 这 里 等 待 上 述 处 理 全 部 完成 

41 Thread.sleep(1000); 

42 } 

43 } 


上 面 的 AIO 客 户 端 看 起 来 代码 很 长 ， 但 实际 上 只 有 三 个 语句 。 








Fe 


第 一 个 语句 为 第 3 行 ， 打 开 AsynchronousSocketChannel 通 道 。 第 二 
个 语句 是 第 4 一 39 行 ， 它 让 客户 端 去 连接 指定 的 服务 器 ， 并 注册 了 一 系 
列 事件 。 第 三 个 语句 是 第 41 行 ， 让 线程 进行 等 待 。 虽 然 第 2 个 语句 看 起 
来 很 长 ， 但 是 它 完全 是 异步 的 ， 因 此 会 很 快 返回 ， 并 不 会 等 待 在 连接 操 
作 的 过 程 中 。 如 果 不 进行 等 待 ， 客 户 端 会 马上 退出 ， 也 就 无 法 继续 工作 
Tg 








第 4 行 ， 客 户 端 进行 网 络 连 接 ， 并 注册 了 连接 成 功 的 回调 函数 
CompletionHandler<Void, Object>。 待 连接 成 功 后 ， 就 会 进入 代码 第 7 
行 。 第 7 行进 行 数据 写 入 ， 回 服务 端 发 送 数据 。 这 个 过 程 也 是 异步 的 ， 
会 很 快 返 回 。 写 入 完成 后 ， 会 通知 回调 接口 CompletionHandler< Integer, 
Object 之 ， 进 入 第 10 行 。 第 10 行 开始 ， 准 备 进行 数据 读 取 ， 从 服务 端 读 
取 回 写 的 数据 。 当 然 ， 第 12 行 的 read0 函 数 也 是 立即 返回 的 ， 成 功 读 取 
所 有 数据 后 ， 会 回调 CompletionHandler<Integer，ByteBuffer 之 接口 ， 进 





入 第 15 行 。 在 第 15 一 16 行 ， 打 印 接收 到 的 数据 。 
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第 6 曹 Java 8 与 并 发 





2014 年 ，Oracle 发 布 了 Java 8 新 版 本 。 对 于 Java 来 说 ， 这 显然 是 一 个 
上 其 有 里 程 碑 意义 的 版 本 。 它 最 主要 的 改进 是 增加 了 函数 式 编程 的 功能 
就 目前 来 襄 ，Java 最 令 人 头痛 的 问题 ， 也 是 受到 最 多 质疑 的 地 方 ， i 
Wiz Java k AMNA. OER AMS ANE BK IN UST RKI 
一 些 司空 见 惯 的 功能 ， 以 至 于 Java 程 序 总 是 见长 的 。 但 是 ， 这 一 切 将 在 
Java 8 的 函数 式 编 程 中 得 到 缓解 。 








严格 来 说 ， 函 数 式 编 程 与 我 们 的 主题 并 没有 太 大 关系 ， 我 似乎 不 应 
该 在 这 里 提 及 它 。 但 是 ， 在 Java 8 中 新 增 的 一 些 与 并 行 相关 的 API， 却 以 
函数 式 编程 的 范式 出 现 ， 为 了 能 让 大 家 更 好 地 理解 这 些 功 能 ， 我 会 先 简 
要 地 介绍 一 下 Java 8 中 的 函数 式 编程 。 


6.1 Javag8 的 函数 了 式 编程 简介 


函数 式 编程 与 面向 对 象 的 设计 方法 在 思路 和 手段 上 都 各 有 千秋 ， 在 
这 里 ， 我 将 简要 介绍 一 下 函数 式 编程 与 面 癌 对 象 相 比 较 的 一 些 特点 和 闫 
异 


o 


6.1.1 AŽUEN- EAR 


在 理解 函数 作为 一 等 公民 这 句 话 时 ， 让 我 们 先 来 看 一 下 一 种 非常 党 
用 的 互联 网 语言 JavaScript， 相 信 大 家 对 它 都 不 会 陌生 。JavaScript 并 不 
是 严格 意义 上 的 函数 式 编程 ， 不 过 ， 它 也 不 是 属于 严格 的 面 癌 对 象 。 但 
是 ， 如 果 你 愿意 ， 你 既 可 以 把 它 当 作 面 同 对 象 语言 ， 也 可 以 把 它 当 作 骆 
数 式 语言 ， 因 此 ， 称 之 为 多 范式 语言 ， 可 能 更 加 合适 。 





如 果 你 使 用 jQuery， 你 可 能 会 经 常 使 用 如 下 的 代码 : 


$("button").click(function(){ 
$("1i").each(function(){ 
alert($(this).text()) 
}); 
}); 


EAX HeachORMNSR, ke NEA we, ERA A iT 
点 时 ， 会 弹出 1 点 的 文本 内 容 。 将 函数 作为 参数 传递 给 万 外 一 个 函 
数 ， 这 是 函数 式 编程 的 特性 之 一 。 


再 来 考察 妃 外 一 个 案例 : 


function f1(){ 
var n=1; 
function f2(){ 

alert(n); 
t 
return f2; 
t 
var result=f1(); 


result(); // 1 


这 也 是 一 段 JavaScript 人 代码。 在 这 段 代 码 中 ， 注 意 函 数位 的 返回 值 ， 
它 返 回 了 闲 数 全 。 在 倒数 第 2 行 ， 返回 的 全 函数 并 赋值 给 result， 实 际 
上 ， 此 时 的 result 就 是 一 个 函数 ， 并 且 指 同 亿 。 对 result 的 调用 ， 就 会 打 
EUn ýE o 


图 数 可 以 作为 另外 一 个 函数 的 返回 值 ， 也 是 函数 式 编程 的 重要 特 
Frio 


6.1.2 ”无 副作用 


函数 的 副作用 指 的 是 函数 在 调用 过 程 中 ， 除 了 给 出 了 返回 值 外 ， 还 
修改 了 函数 外 部 的 状态 。 比 如 ， 函 数 在 调用 过 程 中 ， 修 改 了 茶 一 个 全 局 
状态 。 函 数 式 编程 认为 ， 函 数 的 副 用 作 应 该 被 尽量 避免 。 可 以 想象 ， 如 
果 一 个 函数 肆意 修改 全 局 或 者 外 部 状态 ， 当 系统 出 现 问 题 时 ， 我 们 可 能 
很 难 判 断 究竟 是 哪个 函数 引起 的 问题 ， 这 对 于 程序 的 调试 和 跟踪 是 没有 


好 处 的 。 如 果 函 数 部 是 显 式 函 数 ， 那 么 函数 的 执行 显然 不 会 受到 外 部 或 
者 全 局 信息 的 影响 ， 因 此 ， 对 于 调试 和 排 错 是 有 益 的 。 


TER: 显 式 函 数 指 函数 与 外 界 交 换 数 据 的 唯一 渠道 就 是 参数 和 返回 
值 ， 显 式 函 数 不 会 去 读 取 或 者 修改 函数 的 外 部 状态 。 与 之 相对 的 是 
RADA, ARAR TARRA, BARRIAN S, R 
者 可 能 修改 外 部 信息 。 





然而 ， 完 全 的 无 副作用 实际 上 做 不 到 的 ， 因 为 系统 总 是 需要 获取 或 
者 修改 外 部 信息 的 ， 同 时 ， 模 块 之 间 的 交互 也 极 有 可 能 是 通过 共享 变量 
进行 的 。 如 果 完 全 禁止 副作用 的 出 现 ， 也 是 一 件 让 人 很 不 愉快 的 事情 。 
因此 ， 大 部 分 函数 式 编程 语言 ， 如 Clojure 等 ， 都 允许 副作用 的 存在 。 但 
征 与 面 问 对 象 相 比 ， 这 种 函数 调用 的 副作用 ， 在 函数 式 编程 里 ， 需 要 进 
行 有 效 的 限制 。 








6.1.3 申明 式 的 〈Declarative ) 


函数 式 编程 是 申明 式 的 编程 方式 。 相 对 于 命令 式 〈Imperative) 而 

， 命 令 式 的 程序 设计 喜欢 大 量 使 用 可 变 对 象 和 指令 。 我 们 总 是 习惯 于 
创建 对 象 或 者 变量 ， 并 且 修 改 它们 的 状态 或 者 值 ， 或 者 喜欢 提供 一 系列 
指令 ， 要 求 程序 执行 。 这 种 编程 习惯 在 申明 式 的 函数 式 编 程 中 有 上 所 变 
化 。 对 于 申明 式 的 编程 范式 ， 你 不 再 需要 提供 明确 的 指令 操作 ， 所 有 的 
细节 指令 将 会 更 好 地 被 程序 库 所 封装 ， 你 要 做 的 只 是 提出 你 的 要 求 ， 申 
明 你 的 用 意 即 可 。 


HI 








请 看 下 面 一 段 程序 ， 这 一 段 传统 的 命令 式 编 程 ， 为 了 打印 数组 中 的 
值 ， 我 们 需要 进行 一 个 循环 ， 并 且 每 次 需要 判断 循环 是 否 结束 。 在 循环 


体内 ， 我 们 要 明确 地 给 出 需要 执行 的 语句 和 参数 。 


public static void imperative(){ 
int[] 1Arr={1,3,4,5,6,9,8,7,4,2}; 
for(int i1=0;i<iArr.length;it++) { 


System.out.println(iArr[i]); 


与 之 对 应 的 申明 式 代码 如 下 : 


public static void declarative(){ 
int[] 1Arr={1,3,4,5,6,9,8,7,4,2}; 


Arrays.stream(iArr).forEach(System. out: :printlin); 


可 以 看 到 ， 变 量 数组 的 循环 体 居然 消失 了 ! printin0 函 数 似乎 在 这 
里 也 没有 指定 任何 参数 ， 在 此 ， 我 们 只 是 简单 地 申明 了 我 们 的 用 意 。 有 
天 循环 以 及 判断 循环 是 否 结束 等 操作 都 被 简单 地 封装 在 程序 库 中 。 


6.1.4 不 变 的 对 象 


在 函数 式 编程 中 ， 几 乎 所 有 传递 的 对 象 部 不 会 被 轻 易 修改 。 





请 看 以 下 代码 : 


static int[] arr={1,3,4,5,6,7,8,9,10}; 


Arrays.stream(arr).map((x)->x=x+1).forEach(System.out::println); 


System.out.printin(); 


Arrays.stream(arr).forEach(System.out::println); 


代码 第 2 行 看 似 对 每 一 个 数组 成 员 执 行 了 加 1 的 操作 。 但 是 在 操作 完 
成 后 ， 在 最 后 一 行 ， 打 印 arr 数 组 所 有 的 成 员 值 时 ， 你 还 是 会 有 发现， 数组 
成 员 并 没有 变化 ! 在 使 用 函数 式 编程 时 ， 这 种 状态 是 一 种 常态 ， 几 乎 所 
有 的 对 象 都 拒绝 被 修改 。 这 非常 类 似 于 不 变 模式 。 


6.1.5 易于 并 行 


由 于 对 象 都 处 于 不 变 的 状态 ， 因 此 函数 式 编 程 更 加 易于 并 行 。 实 际 
上 ， 你 甚至 完全 不 用 担心 线程 安全 的 问题 。 我 们 之 所 以 要 关注 线程 安 
全 ， 一 个 很 重要 的 原因 是 当 多 个 线程 对 同一 个 对 象 进行 写 操作 时 ， 容 易 
将 这 个 对 象 “ 写 坏 ”。 但 是 ， 由 于 对 象 是 不 变 的 ， 因 此 ， 在 多 线程 环境 
下 ， 也 就 没有 必要 进行 任何 同步 操作 。 这 样 不 仅 有 利于 并 行 化 ， 同 时 ， 
在 并 行 化 后 ， 由 于 没有 同步 和 锁 机 制 ， 其 性 能 也 会 比较 好 。 


6.1.6 SDA 


通常 情况 下 ， 函 数 式 编程 更 加 简明 扼要 ，Clojure 语 言 (一 种 运行 于 
JVM 的 函数 式 语 言 ) 的 爱好 者 就 宣称 ， 使 用 Clojure 可 以 将 Java 代 码 行 数 
减少 到 原 有 的 十 分 之 一 。 一 般 说 来 ， 精 人 简 的 代码 更 易于 维护 。 引 入 函数 
式 编程 范式 后 ， 我 们 可 以 使 用 Java 用 更 少 的 代码 完成 更 多 的 工作 。 

















请 看 下 面 这 个 例子 ， 对 于 数组 中 每 一 个 成 员 ， 首先 判断 是 否 是 奇 
数 ， 如 果 是 奇数 ， 则 执行 加 1， 并 最 终 打印 数 组 内 所 有 成 员 。 


数组 定义 : 


static int[] arr={1,3,4,5,6,7,8,9,10}; 


传统 的 处 理 方式 : 


for(int 1=0;i<arr.length;i++){ 
if (arr[i]%2!=0) { 
arr[i]++; 
$ 


System.out.printin(arr[i]); 


使 用 函数 式 方式 : 


Arrays.stream(arr).map(x->(x%2==0?x:x+1)).forEach(System.out: 


ALLA BI, KAN WA EA Be H. f o 


br: 


6.2 PAŽIN Sn FE aE ly 


在 正式 进入 函数 式 编程 之 前 ， 有 必要 先 了 解 一 下 Java 8 为 支持 函数 
式 编 程 所 做 的 基础 性 的 改进 ， 这 里 ， 将 简要 介绍 一 下 FunctionalInterface 
注释 、 接 口 默认 方法 和 方法 句柄 。 





6.2.1 FunctionalInterface 注 释 


Java 8 提出 了 函数 式 接口 的 概念 。 所 谓 函 数 式 接口 ， 简 单 来 说 ， 就 
是 只 定义 了 单一 抽象 方法 的 接口 。 比 如 下 面 的 定义 : 


@FunctionalInterface 
public static interface IntHandler{ 


void handle(int i); 


注释 FunctionalInterface 用 于 表明 IntHandler 接 口 是 一 个 函数 式 接口 ， 
该 接口 被 定义 为 只 包含 一 个 抽象 方法 handle0， 因 此 它 符 合 函 数 式 接口 
的 定义 。 如 果 一 个 函数 满足 函数 式 接口 的 定义 ， 那 么 即使 不 标注 为 
@FunctionalInterface， 编 译 吉 依然 会 把 它 看 做 函数 式 接口 。 这 有 点 像 
@Override 注 释 ， 如 果 你 的 函数 符合 重 载 的 要 求 ， 无 论 你 是 否 标注 了 
@Override， 编 译 器 都 会 识别 这 个 重 载 图 数 ， 但 一 旦 你 进行 了 标注 ， 而 
实际 的 代码 不 符合 规范 ， 那 么 就 会 得 到 一 个 编译 错误 。 如 图 6.1 所 示 ， 
展示 了 一 个 不 符合 规范 ， 却 被 标注 为 @FunctionalInterfacede 接 口 。 很 显 
然 ， 该 IntHandler 包 含 两 个 抽象 方法 ， 因 此 不 符合 函数 式 接口 的 要 求 ， 


又 因为 IntHandler 接 口 被 标注 为 函数 式 接口 ， 产 生 矛 盾 ， 故 编译 出 错 。 


9 @Functionalinterface 

G10 public static interface IntHandler{ 
void handle(int i); 

void handle2(int i); 





图 6-1 不 符合 规范 的 函数 式 接口 


这 里 需要 强调 的 是 ， 函 数 式 接口 只 能 有 一 个 抽象 方法 ， 而 不 是 只 能 
有 一 个 方法 。 这 分 两 点 来 说 明 : 首先 ， 在 Java 8 中 ， 接 口 运 行 存 在 实例 
方法 (参见 下 节 的 “接口 默认 方法 ”) ， 其 次 任何 被 java.lang.Object 实 现 
的 方法 ， 都 不 能 视 为 抽象 方法 ， 因 此 ， 下 面 的 NonFunc 接 口 不 是 函数 式 
接口 ， 因 为 equals0 方 法 在 java.lang.Object 中 已 经 实现 。 





interface NonFunc { 


boolean equals(Object obj); 


同 理 ， 下 面 实现 的 IntHandler 接 口 符合 函数 式 接口 要 求 ， 虽 然 看 起 
来 它 不 像 ， 但 实际 上 它 是 一 个 完全 符合 规范 的 函数 式 接口 。 


QFunctionalInterface 
public static interface IntHandler{ 
void handle(int i); 


boolean equals(Object obj); 


函数 式 接 口 的 实例 可 以 由 方法 引用 或 者 lambda 表 达 式 进行 构造 ， 这 
个 我 们 将 在 后 面 进一步 举例 说 明 。 


6.2.2 ”接口 默认 方法 


在 Java 8 之 前 的 版 本 ， 接 口 只 能 包含 抽象 方法 。 但 从 Java 8 之 后 ， 接 
口 也 可 以 包含 大 干 个 实例 方法 。 这 一 改进 使 得 Java 8 拥有 了 类 似 于 多 继 
承 的 能 力 。 一 个 对 象 实 例 ， 将 拥有 来 自 于 多 个 不 同 接口 的 实例 方法 。 





比如 ， 对 于 接口 [Horse， 实 现 如 下 : 


public interface IHorse{ 
void eat(); 
default void run(){ 


System.out.println("hourse run"); 


UW 





在 Java 8 中 ， 使 用 default 关 键 字 ， 可 以 在 接口 内 定义 实例 方法 。 注 
意 ， 这 个 方法 并 非 抽 象 方法 ， 而 是 拥有 特定 逻辑 的 具体 实例 方法 。 





所 有 的 动物 都 能 自由 呼吸 ， 所 以 ， 这 里 可 以 再 定义 一 个 IAnimal 接 
口 ， 它 也 包含 一 个 默认 方法 breath()。 


public interface IAnimal { 
default void breath(){ 


System.out.printin("breath"); 


又 是 马 和 驴 的 杂交 物种 ， 因 此 又 (Mule) 可 以 实现 为 IHorse， 同 时 


又 也 是 动物 ， 因 此 有 : 


public class Mule implements IHorse, IAnimal{ 

@Override 

public void eat() { 
System.out.printin("Mule eat"); 

J 

public static void main(String[] args) { 
Mule m=new Mule(); 
m.run(); 


m.breath(); 





注意 上 述 代码 中 Mule 实 例 同时 拥有 来 自 不 同 接口 的 实现 方法 。 这 在 
Java 8 之 前 是 做 不 到 的 。 从 某 种 程度 上 说 ， 这 种 模式 可 以 弥补 Java 单 一 
继承 的 一 些 不 便 。 但 同时 也 要 知道 ， 它 也 将 遇 到 和 多 继承 相同 的 问题 ， 
如 图 6.2 所 示 。 如 果 IDonkey 也 存在 一 个 默认 的 run(0) 方 法 ， 那 么 同时 实现 
它们 的 Mule， 束 会 不 知 所 措 ， 因 为 它 不 知道 应 该 以 哪个 方法 为 准 。 


[we |5 | [Donkey af 
vun] Sy [rua 
wee ; 
Mule AR 
7 A an run ? 


图 6-2 接口 默认 方法 带 来 的 多 继承 问题 








增加 一 个 IDonkey 的 实现 : 


public interface IDonkey{ 
void eat(); 
default void run(){ 


System.out.println("Donkey run"); 


修改 又 Mule 的 实现 如 下 ， 注 意 它 同 时 实现 了 IHorse 和 IDonkey: 


public class Mule implements IHorse, IDonkey, IAnimal{ 
@Override 
public void eat() { 


System.out.printin("Mule eat"); 


} 

public static void main(String[] args) { 
Mule m=new Mule(); 
m.run(); 


m.breath(); 


此 时 ， 由 于 IHorse 和 IDonkey 拥 有 相同 的 默认 实例 方法 ， 故 编译 絮 
会 抛 出 一 个 错误 : 


Duplicate default methods named run with the parameters () and () 


IDonkey and IHorse 


为 了 让 Mule 同 时 实现 IHorse 和 IDonkey， 在 这 里 ， 我 们 不 得 不 重新 
实现 一 下 run(0) 方 法 ， 让 编译 器 可 以 进行 方法 绑 定 。 修 改 Mule 的 实现 如 
下 : 


public class Mule implements IHorse, IDonkey, IAnimal{ 
@Override 
public void run(){ 


IHorse.super.run(); 


@Override 

public void eat() { 
System.out.println("Mule eat"); 

} 

public static void main(String[] args) { 
Mule m=new Mule(); 
m.run(); 


m.breath(); 


在 这 里 ， 将 Mule 的 run0 方 法 委托 给 IHorse 实 现 ， 当 然 ， 大 家 也 可 以 
有 目 己 的 实现 。 





接口 默认 实现 对 于 整个 函数 式 编程 的 流 式 表达 非常 重要 。 比 如 ， 大 
家 熟悉 的 java.util.Comparator 接 口 ， 它 在 JDK 1.2 时 就 已 经 被 引入 ， 用 于 


在 排序 时 给 出 两 个 对 象 实例 的 具体 比较 逻辑 。 在 Java 8F, Comparator 
接口 新 增 了 奉 干 个 默认 方法 ， 用 于 多 个 比较 器 的 整合 。 其 中 一 个 第 用 的 
默认 方法 如 下 : 


default Comparator<T> thenComparing(Comparator<? super T> othe 
Objects. requireNonNull(other ); 
return (Comparator<T> & Serializable) (c1, c2) -> { 
int res = compare(ci, c2); 


return (res != 0) ? res : other.compare(ci, c2); 


AS PERU, ETAF, BOM AY DASE ae A EEIT 
AWS ARIE, Eon, On PRISMS hes, “EEF AT 
度 排序 ， 继 而 按照 大 小 写 不 敏感 的 字母 顺序 排序 。 








Comparator<String> cmp = Comparator.comparingInt(String: :length) 


. thenComparing(String.CASE_INSENSITIVE_ORDER) ; 


6.2.3 lambda 表达 式 


lambda 表 达 式 可 以 说 是 函数 式 编程 的 核心 。lambda 表 达 式 即 匿 名 函 
数 ， 它 是 一 段 没有 函数 名 的 函数 体 ， 可 以 作为 参数 直接 传递 给 相关 的 调 
用 者 。lambda 表 达 式 极 大 地 增强 了 Java 语 言 的 表达 能 


下 例 展示 了 lambda 表 达 式 的 使 用 ， 在 forEach() 函 数 中 ， 传 入 的 就 是 
一 个 lambda 表 达 式 ， 它 完成 了 对 元 素 的 标准 输出 操作 。 可 以 看 到 这 上 段 表 











达 式 并 不 像 函 数 一 样 有 名 字 ， 非 常 类 似 匿 名 内 部 类 ， 筷 只 是 简单 地 描述 
了 应 该 执行 的 代码 段 。 





List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5, 6); 


numbers.forEach((Integer value) -> System.out.printin(value) ); 


和 匿名 对 象 一 样 ，lambda 表 达 式 也 可 以 访问 外 部 的 局 部 变量 ， 如 下 
所 示 : 


final int num = 2; 
Function<Integer, Integer> stringConverter = (from) -> from * n 


System.out.printin(stringConverter.apply(3)); 


上 述 代码 可 以 编译 通过 ， 正 常 执行 ， 并 输出 6。 与 匿名 内 部 对 象 一 
样 ， 在 这 种 情况 下 ， 外 部 的 num 变 量 必 须 申明 为 final， 这 样 才 能 保证 在 
lambda 表 达 式 中 合法 的 访问 它 。 


但 奇妙 的 是 ， 对 于 lambda 表 达 式 而 言 ， 即 使 去 挥 上 述 的 final 定 义 ， 
程序 依然 可 以 编译 通过 ! 但 干 万 不 要 以 为 这 样 你 就 可 以 修改 hum 的 值 
了 。 实 际 上 ， 这 只 是 Java 8 做 了 一 个 手 人 耳目 的 小 处 理 ， 它 会 自动 地 将 
在 lambda 表 达 式 中 使 用 的 变量 视 为 final。 因 此 ， 下 述 代 码 是 可 以 编译 通 
过 的 : 


int num = 2; 
Function<Integer, Integer> stringConverter = (from) -> from * n 


System.out.printin(stringConverter.apply(3)); 


但 是 ， 如 果 像 下 面 这 么 写 ， 就 不 行 : 


int num = 2; 


Function<Integer, Integer> stringConverter = (from) -> from * n 
num++; 


System.out.printin(stringConverter.apply(3)); 
上 述 的 num++ 会 引起 一 个 编译 错误 : 


Local variable num defined in an enclosing scope must be final or 


6.2.4 ”方法 引用 


方法 引用 是 Java 8 中 提出 的 用 来 简化 lambda 表 达 式 的 一 种 手段 。 它 
通过 类 名 和 方法 名 来 定位 到 一 个 静态 方法 或 者 实例 方法 。 











方法 引用 在 Java 8 中 的 使 用 非常 灵活 。 忌 的 来 说 ， 可 以 分 为 以 下 几 
种 。 


静态 方法 引用 : ClassName::methodName 

实例 上 的 实例 方法 引用 : instanceReference::methodName 
超 类 上 的 实例 方法 引用 : super::methodName 

类 型 上 的 实例 方法 引用 : ClassName::methodName 

构造 方法 引用 : Class::new 

。 数组 构造 方法 引用 : TypeName[]::new 





首先 ， 方 法 引用 使 用 “::* 定 义 ,，“::” 的 前 半 部 分 表示 类 名 或 者 实例 
名 ， 后 半 部 分 表示 方法 名 称 。 如 果 是 构造 函数 ， 则 使 用 new 表 示 。 


下 例 展示 了 方法 引用 的 基本 使 用 : 


public class InstanceMethodRef { 
public static void main(String[] args) { 
List<User> users=new ArrayList<User>(); 
for(int 1=1;1<10;1i++){ 
users.add(new User(i, "billy"+Integer.toString(i))); 


i 


users.stream().map(User: :getName) .forEach(System. out: :pri 





对 于 第 1 个 方法 引用 “User::getName”， 表 示 User 类 的 实例 方法 。 在 
执行 时 ，Java 会 自动 识别 流 中 的 元 素 〈 这 里 指 User 实 例 ) 是 作为 调用 目 
标 还 是 调用 方法 的 参数 。 在 “User::getName” 中 ， 显 然 流 内 的 元 素 都 应 该 
作为 调用 目标 ， 因 此 实际 上 ， 在 这 里 调用 了 每 一 个 User 对 象 实例 的 
getName() 方 法 ， 并 将 这 些 User 的 name 作 为 一 个 新 的 流 。 同 时 ， 对 于 这 
里 得 到 的 所 有 name， 使 用 方法 引用 System.out::println 进 行 处 理 。 这 里 的 
System.out 为 PrintStream 对 象 实 例 ， 因 此 ， 这 里 表示 System.out 实 例 的 
println 方 法 ， 系 统 也 会 自动 判断 ， 流 内 的 元 素 此 时 应 该 作为 方法 的 参数 
传 入 ， 而 不 是 调用 目标 。 








一 般 来 说 ， 如 果 使 用 的 是 静态 方法 ， 或 者 调用 目标 明确 ， 那 么 流失 
的 元 素 会 目 动 作为 参数 使 有 用。 如果 函数 引用 表示 实例 方法 ， 并 且 不 存在 
调用 目标 ， 那 么 流 内 元 素 就 会 日 动 作为 调用 目标 。 











因此 ， 如 果 一 个 类 中 存在 同名 的 实例 方法 和 静态 函数 ， 那 么 编译 右 
就 会 感到 很 困惑 ， 因 为 此 时 ， 它 不 知道 应 该 使 用 哪个 方法 进行 调用 。 它 
既 可 以 选择 同名 的 实例 方法 ， 将 流 内 元 素 作为 调用 目标 ， 也 可 以 使 用 静 
态 方法 ， 将 流 元 素 作 为 参数 。 





请 看 下 面 的 例子 : 


public class BadMethodRef { 
public static void main(String[] args) { 
List<Double> numbers=new ArrayList<Double>(); 
for(int 1=1;1<10;i++){ 
numbers.add(Double.valueOf(i)); 


} 


numbers.stream().map(Double::toString).forEach(System.out 


上 述 代码 试图 将 所 有 的 Double 元 素 转 为 String 并 将 其 输出 ， 但 是 很 
不 季 ， 在 Double 中 同时 存在 以 下 两 个 函数 





public static String toString(double d) 


public String toString() 


此 时 ， 对 函数 引用 的 处 理 就 出 现 了 歧义 ， 因 此 ， 这 段 代码 在 编译 时 
就 会 抛 出 如 下 错误 : 


Ambiguous method reference: both toString() and toString(double) 


eligible 





方法 引用 也 可 以 直接 使 用 构造 浮 数 。 首 先 ， 查 看 模型 类 User 的 定 
X: 


public class User{ 


private int id; 


private String name; 


public User(int id,String name) { 
this.id=id; 
this .name=name; 


} 
// 这 里 省 略 对 字段 的 Setter 和 getter 


下 面 的 方法 引用 调用 了 User 的 构造 函数 : 


public class ConstrMethodRef { 
@FunctionalInterface 
interface UserFactory<U extends User> { 


U create(int id, String name); 


static UserFactory<User> uf=User: :new; 


public static void main(String[] args) { 
List<User> users=new ArrayList<User>(); 
for(int 1=1;1<10;i++){ 
users.add(uf.create(i, "billy"+Integer.toString(i))); 


} 


users.stream().map(User::getName).forEach(System.out::pri 


在 此 ，UserFactory 作 为 User 的 工厂 类 ， 是 一 个 函数 式 接口 。 当 使 用 
User::new 创 建 接口 实例 时 ， 系 统 会 根据 UserFactory.create() 的 函数 签名 
来 选择 合适 的 User 构 造 函 数 ， 在 这 里 ， 很 显然 融 是 public User(int 
id,String name)。 在 创建 UserFactory 实 例 后 ， 对 UserFactory.createO) 的 调 
用 ， 都 会 委托 给 User 的 实际 构造 函数 进行 ， 从 而 创建 User 对 象 实例 。 


6.3 一 步 一 步 走 入 函数 式 编程 


在 了 解 了 Java 8 的 一 些 新 特性 后 ， 就 可 以 正式 开始 进入 函数 式 编 程 
了 。 为 了 能 让 大 家 更 快 地 理解 函数 式 编程 ， 我 们 先 从 简单 的 例子 开始 。 


static int[] arr={1,3,4,5,6,7,8,9,10}; 


public static void main(String[] args) { 
for(int i:arr){ 


System.out.println(1); 


XR RES AF a REAR. HEIT S BCE IT EN, X 
是 传统 的 做 法 。 如 果 使 用 Java 8 中 的 流 ， 那 么 可 以 写成 这 样 : 


Static int) arn 34007079 160} 


public static void main(String[] args) { 
Arrays.stream(arr).forEach(new IntConsumer() { 
@Override 
public void accept(int value) { 


System.out.printin(value); 


+); 


JER: Arrays. stream) 方法 返回 了 一 个 流 对 象 。 类 似 于 集合 或 者 
数组 ， 流 对 象 也 是 一 个 对 象 的 集合 ， 它 将 给 予 我 们 遍历 处 理 流 内 元 
素 的 功能 。 





这 里 值得 注意 的 是 这 个 流 对 象 的 forEach() 方 法 ， 它 接收 一 个 
IntConsumer 接 口 的 实现 ， 用 于 对 每 个 流 内 的 对 象 进 行 处 理 。 之 所 以 是 
IntConsumer 接 口 ， 因 为 当前 流 是 IntStream， 也 就 是 装 有 Integer 元 素 的 
流 ， 因 此 ， 它 自然 需要 一 个 处 理 Integer 元 素 的 接口 。 消 数 forEach() 会 挨 
个 将 流 内 的 元 素 送 入 IntConsumer 进 行 处 理 ， 循 环 过 程 被 封装 在 forEachO 
内 部 ， 也 就 是 JDK 框 架 内 。 


除了 IntStream 流 外 ，Arrays.stream() 还 支持 DoubleStream、 
LongStream 和 普通 的 对 象 流 Stream， 这 完全 取决 于 它 所 接受 的 参数 ， 如 
图 6.3 所 示 。 


stream 
4 ®© Arrays 

es stream(T[]) <T> : Stream<T> 
es stream(T[], int, int) <T> : Stream<T> 
es stream(int[]) : IntStream 
es stream(int{], int, int) : IntStream 
es stream(long[]) : LongStream 
es stream(longj], int, int) : LongStream 
es stream(double{]) : DoubleStream 
es stream(double[], int, int) : DoubleStream 





图 6.3 Stream 流 的 几 种 类 型 


但 这 样 的 写法 可 能 还 不 能 让 人 满意 ， 代 码 量 似乎 比 原先 更 多 ， 而 且 
除了 引入 了 不 必要 的 接口 和 匿名 类 等 复 林 性 外 ， 似 乎 也 看 不 出 来 有 什么 
太 大 的 好 处 。 但 是 ， 我 们 的 脚步 并 未 就 此 打住 。 试 想 ， 既 然 forEach() 函 
数 的 参数 是 可 以 从 上 下 文中 推导 出 来 的 ， 那 为 什么 还 要 不 大 其 烦 地 写 出 














来 呢 ? EA BITES LE, BCA on PE a I | 于 是 : 


static int[] arr={1,3,4,5,6,7,8,9,10}; 


public static void main(String[] args) { 
Arrays.stream(arr).forEach((final int x)-> { 
System.out.println(x); 
t); 


从 上 述 代 码 中 可 以 看 到 ，IntStream 接 口 名 称 被 省 略 了 ， 这 里 只 使 用 
了 参数 名 和 一 个 实现 体 ， 看 起 来 简洁 很 多 了 。 但 是 还 不 够 ， 因 为 参数 的 
类 型 也 是 可 以 推导 的 。 既 然 是 IntConsumer 接 口 ， 参 数 自然 是 int 了， 于 


H 
JE: 





static int[] arr={1,3,4,5,6,7,8,9,10}; 


public static void main(String[] args) { 
Arrays.stream(arr).forEach((x)-> { 
System.out.println(x); 
}); 


好 了 ， 现 在 连 参 数 类 型 也 省 略 了， 但 是 这 两 个 花 括 写 特别 碍 眼 。 虽 
然 它们 对 程序 没有 什么 影响 ， 但 是 为 了 简单 的 一 句 执 行 语句 要 加 上 一 对 
化 括号 也 实 属 没有 必要 ， 那 干脆 也 去 掉 吧 ! 去 掉 花 括 写 后 ， 为 了 清晰 起 
见 ， 把 参数 申明 和 接口 实现 就 放 在 一 行 吧 ! 











static int[] arr={1,3,4,5,6,7,8,9,10}; 


public static void main(String[] args) { 


Arrays.stream(arr).forEach((x)->System.out.printin(x)); 


这 样 看 起 来 就 好 多 了 。 此 时 ，forEach() 函 数 的 参数 依然 是 
IntConsumer， 但 是 它 却 以 一 种 新 的 形式 被 定义 ， 这 就 是 lambda 表 达 式 。 
表达 式 由 “> ”分 割 ， 左 半 部 分 表示 参数 ， 右 半 部 分 表示 实现 体 。 因 
此 ， 我 们 也 可 以 简单 地 理解 lambda 表 达 式 只 是 匿名 对 象 实 现 的 一 种 新 的 

方式 。 ERE, TERI. 











有 兴趣 的 读者 可 以 使 用 虚拟 机 参数 - 
Djdk.internal.lambda.dumpProxyClasses 启 动 带 有 lambda 表 达 式 的 Java 小 程 
序 ， 访 参数 会 将 lambda 表 达 式 相关 的 中 间 类 型 进行 输出 ， 方 便 调 试 和 学 
习 。 在 本 例 中 ， 输 出 了 HelloFunction6$$Lambda$1.class 类 ， 使 用 以 下 命 
令 进 行 并 发 汇编 操作 : 





javap -p -v HelloFunction6$$Lambda$1.class 


在 输出 结果 中 ， 可 以 清楚 地 看 到 : 


final class geym.java8.func.ch3.HelloFunction6$$Lambda$1 implemen 
java.util. function. IntConsumer 
省 略 部 分 得 出 
public void accept(int); 
descriptor: (I)V 
flags: ACC_PUBLIC 


Code: 
stack=1, locals=2, args_size=2 
0: iload 1 
1: invokestatic #17 // Method geym/java8/func/ch3/HelloFun 


4: return 








限于 篇 幅 有 限 ， 这 里 只 给 出 了 我 们 关心 的 内 容 。 首 先 ， 这 个 中 间 类 
型 确实 实现 了 IntConsumer 接 口 。 其 次 ， 在 实现 accept(0) 方 法 时 ， 它 内 部 
委托 给 了 一 个 名 为 HelloFunction6.lambda$00 的 方法 。 可 以 推测 ， 这 个 方 
法 也 是 编译 时 自动 生成 的 。 


使 用 以 下 命令 查看 HelloFunction6 的 编译 结果 : 


javap -p -v HelloFunction6 


我 们 很 惊喜 地 找到 了 期 待 已 久 的 lambda$00 方 法 ， 其 实现 如 下 : 


private static void lambda$0(int); 
descriptor: (I)V 
flags: ACC_PRIVATE, ACC_STATIC, ACC_SYNTHETIC 
Code: 


stack=2, locals=1, args_size=1 


0: getstatic #41 // Field java/lang/Syst 
3: iload 0 
4: invokevirtual #47 // Method java/io/Print 
7: return 


它 被 实现 为 一 个 私有 的 静态 方法 ， 实 现 内 容 束 是 简单 地 进行 了 
System.out.println() 的 调用 ， 也 正 是 我 们 代码 中 lambda 表 达 式 的 内 容 。 


由 此 ， 可 以 看 到 ，Java 8 中 对 lambda 表 达 式 的 处 理 几 乎 等 同 于 匿名 
类 的 实现 ， 但 是 在 写法 上 和 编程 范式 上 有 了 明显 的 区 别 。 


不 过 ， 简 化 代码 的 流程 并 没有 结束 ， 在 上 一 节 中 已 经 担 到 ，Java 8 
还 文 持 了 方法 引用 ， 通 过 方法 引用 的 推导 ， 你 其 全 连 参 数 申 明和 传递 都 
可 以 省 略 。 


static int[] arr={1,3,4,5,6,7,8,9,10}; 


public static void main(String[] args) { 


Arrays.stream(arr).forEach(System.out::printlin); 


至 此 ， 欢 迎 大 家 正式 进入 Java Beh TE BCE, ASHE x wb 
的 lambda 表 达 式 的 解析 和 工作 原理 已 经 介绍 完毕 。 


使 用 lambda 表 达 式 不 仅 可 以 简化 匿名 类 的 编写 ， 与 接口 的 默认 方法 
相 结合 ， 还 可 以 使 用 更 顺畅 的 流 式 API 对 各 种 组 件 进 行 更 自由 的 装配 。 





下 面 这 个 例子 对 集合 中 所 有 元 系 进 行 两 次 输出 ， 一 次 输出 到 标准 错 
误 ， 一 次 输出 到 标准 输出 中 。 


static int[] arr={1,3,4,5,6,7,8,9,10}; 


public static void main(String[] args) { 
IntConsumer outprintln=System.out::println; 
IntConsumer errprintln=System.err::println; 


Arrays.stream(arr).forEach(outprintin.andThen(errprintin) ); 


这 里 首先 使 用 函数 引用 ， 直 接 定 义 了 两 个 IntConsumer 接 口 实例 ， 
一 个 指 同 标准 输出 ， 另 一 个 指向 标准 错误 。 使 用 接口 默认 函数 
IntConsumer.addThen0， 将 两 个 IntConsumer 进 行 组 合 ， 得 到 一 个 新 的 
IntConsumer， 这 个 新 的 IntConsumer 会 依次 调用 outprinttn 和 errprinttn， 完 


成 对 数组 中 元 素 的 处 理 。 
其 中 IntConsumer.addThen0 的 实现 如 下 ， 仅 供 大 家 参考 : 


default IntConsumer andThen(IntConsumer after) { 
Objects.requireNonNull(after ); 


return (int t) -> { accept(t); after.accept(t); }; 


可 以 看 到 ，addThen() 方 法 返回 一 个 新 的 IntConsumer， 这 个 新 的 
IntConsumer 会 先 调 用 第 1 个 IntConsumer 进 行 处 理 ， 接 着 调用 第 2 个 
IntConsumer 处 理 ， 从 而 实现 多 个 处 理 器 的 整合 。 这 种 操作 手法 在 Java 8 
的 函数 式 编程 中 极其 常见 ， 请 大 家 留意 。 


6.4 并行 流 与 并 行 排序 


Java 8 中 ， 可 以 在 接口 不 变 的 情况 下 ， 将 流 改 为 并 行 流 。 这 样 ， 就 
可 以 很 自然 地 使 用 多 线程 进行 集合 中 的 数据 处 理 。 


6.4.1 ”使 用 并 行 流 过 小 数据 


现在 让 我 们 考 夸 这 么 一 个 简单 的 案例 ， 我 们 希望 可 以 统计 1 一 
1000000 内 所 有 的 质数 的 数量 。 首 先 ， 我 们 需要 一 个 判断 质数 的 函数 : 


public class PrimeUtil { 
public static boolean isPrime(int number) { 

int tmp = number; 

if (tmp < 2) { 
return false; 

i 

for (int i = 2; Math.sqrt(tmp) >= i; i++) { 
if (tmp % i == 0) { 


return false; 


i 


return true; 


上 述 函 数 给 定 一 个 数字 ， 如 果 这 个 数字 是 质数 就 返回 true， 人 否则 返 
回 false。 


接着 ， 使 用 函数 式 编程 统计 给 定 范 围 内 所 有 的 质数 : 
IntStream.range(1, 1000000).filter(PrimeUtil::isPrime).count(); 


上 述 代 码 首 先生 成 一 个 1 到 1000000 的 数字 流 。 接 着 使 用 过 滤 函 数 ， 
只 选择 所 有 的 质数 ， 最 后 进行 数量 统计 。 


上 述 代码 是 串 行 的 ， 将 筷 改 造成 并 行 计 算 非常 简单 ， 只 需要 将 流 并 
行 化 即 可 : 


IntStream.range(1, 1000000).parallel().filter(PrimeUtil: :isPrime) 


上 述 代码 中 ， 首 先 parallel() 方 法 得 到 一 个 并 行 流 ， 接 着 ， 在 并 行 流 
上 进行 过 滤 ， 此 时 ，PrimeUtil.isPrime() 函 数 会 被 多 线程 并 发 调用 ， 应 用 
于 流 中 的 所 有 元 素 。 


6.4.2 ”从 集合 得 到 并 行 流 


在 函数 式 编程 中 ， 我 们 可 以 从 集合 得 到 一 个 流 或 者 并 行 流 。 下 面 这 
段 代 码 试图 统计 集合 内 所 有 学 生 的 平均 分 : 





List<Student> ss=new ArrayList<Student>(); 


double ave=ss.stream().mapToInt(s->s.score).average().getAsDouble 


从 集合 对 象 List 中 ， 我 们 使 用 stream0) 方 法 可 以 得 到 一 个 流 。 如 果 希 
望 将 这 段 代 码 并 行 化 ， 则 可 以 使 用 parallelStream() 函 数 。 


double ave=ss.parallelStream().mapToInt(s->s.score).average().gel 


可 以 看 到 ， 将 原 有 的 串 行 方式 改造 成 并 行 执行 是 非常 容易 的 。 


6.4.3 FFT HE 


除了 并 行 流 外 ， 对 于 普通 数组 ，Java ”8 中 也 提供 了 简单 的 并 行 功 
能 。 比 如 ， 对 于 数组 排序 ， 我 们 有 Arrays.sort(0) 方 法 。 当 然 这 是 串 行 排 
序 ， 但 在 Java 8 中 ， 我 们 可 以 使 用 新 增 的 Arrays. parallelSort() 方 法 直接 使 
用 并 行 排序 。 


比如 ， 你 可 以 这 样 使 用 : 


int[] arr=new int[10000000]; 


Arrays.parallelSort(arr); 


除了 并 行 排序 外 ，Arrays 中 还 增加 了 一 些 API 用 于 数组 中 数据 的 赋 
值 ， 比如 : 


public static void setAll(int[] array, IntUnaryOperator generator 





这 是 一 个 函数 式 味道 很 浓 的 接口 ， 它 的 第 2 个 参数 是 一 个 函数 式 接 
口 。 如 果 我 们 想 给 数组 中 每 一 个 元 素 都 附 上 一 个 随机 值 ， 则 可 以 这 人 么 
做 : 


Random r=new Random( ) ; 


Arrays.setAll(arr, (1)->r.nextInt()); 


当然 ， 以 上 过 程 是 串 行 的 。 但 是 只 要 使 用 setAl10 对 应 的 并 行 版 本 ， 


你 就 可 以 很 快 将 它 执 行 在 多 个 CPU 上 : 


Random r=new Random( ); 


Arrays.parallelSetAll (arr, (i)->r.nextInt()); 


6.5 ”增强 的 Future: 
CompletableFuture 


CompletableFuture 是 Java ”8 新 增 的 一 个 超大 型 工具 类 。 为 什么 说 它 
大 呢 ? 因 为 一 方面 ， 它 实现 了 Future 接 口 ， 而 更 重要 的 是 ， 它 也 实现 了 
CompletionStage 接 口 。CompletionStage 接 口 也 是 在 Java 8 中 新 增 的 。 而 
CompletionStage 接 口 拥有 多 达 约 40 种 方法 ! 是 的 ， 你 没有 看 错 ， 这 看 起 
来 完全 不 符合 设计 原则 中 所 谓 的 “单方 法 接口 "”， 但 是 在 这 里 ， 它 就 这 么 
存在 了 。 这 个 接口 之 所 以 拥有 如 此 众多 的 方法 ， 是 为 了 函数 式 编程 中 的 
流 式 调用 准备 的 。 通 过 CompletionStage 提 供 的 接口 ， 我 们 可 以 在 一 个 执 
行 结果 上 进行 多 次 流 式 调用 ， 以 此 可 以 得 到 最 终结 果 。 比 如 ， 你 可 以 在 
一 个 CompletionStage 上 进行 如 下 调用 : 








stage.thenApply(x -> square(x)).thenAccept(x -> System.out.print 


System.out.println()) 


这 一 连 串 的 调用 就 会 换个 执行 。 


6.5.1 SEK I WMF 


CompletableFuture 和 Future 一 样 ， 可 以 作为 函数 调用 的 契约 。 如 果 
你 向 CompletableFuture 请 求 一 个 数据 ， 如 果 数 据 还 没有 准备 好 ， 请 求 线 
程 就 会 等 待 。 而 让 人 惊喜 的 是 ， 通 过 CompletableFuture， 我 们 可 以 手动 
设置 CompletableFuture 的 完成 状态 。 


01 public static class AskThread implements Runnable { 


02 CompletableFuture<Integer> re = null; 
03 

04 public AskThread(CompletableFuture<Integer> re) { 
05 this.re = re; 

06 } 

07 

08 @Override 

09 public void run() { 

10 int myRe = 0; 

11 try { 

12 myRe = re.get() * re.get(); 

13 } catch (Exception e) { 

14 } 

15 System.out.println(myRe); 

16 } 

1y 站 

18 


19 public static void main(String[] args) throws InterruptedExcep 





20 final CompletableFuture<Integer> future = new Completable 
21 new Thread(new AskThread(future)).start(); 

22 // 模拟 长 时 间 的 计算 过 程 

23 Thread.sleep(1000) ) 

24 // 告知 完成 结果 

25 future.complete(60); 


26 } 


上 述 代 码 在 第 1 一 17 行 ， 定 义 了 一 个 AskThread 线 程 。 它 接收 一 个 
CompletableFuture 作 为 其 构造 函数 ， 它 的 任务 是 计算 CompletableFuture 
表示 的 数字 的 平方 ， 并 将 其 打印 。 


代码 第 20 行 ， 我 们 创建 一 个 CompletableFuture 对 象 实例 ， 第 21 行 ， 
我 们 将 这 个 对 象 实例 传递 给 这 个 AskThread 线 程 ， 并 启动 这 个 线程 。 此 
时 ，AskThread 在 执行 到 第 12 行 代码 时 会 阻塞 ， 因 为 CompletableFuture 中 
根本 没有 它 所 需要 的 数据 ， 整 个 CompletableFuture 处 于 未 完成 状态 。 第 
23 行 用 于 模拟 长 时 间 的 计算 过 程 。 当 计算 完成 后 ， 可 以 将 最 终 数据 载 入 
CompletableFuture， 并 标记 为 完成 状态 〈 第 25 行 ) 。 





当 第 25 行 代码 执行 后 ， 表 示 CompletableFuture 已 经 完成 ， 因 此 
AskThread 就 可 以 继续 执行 了 。 


6.5.2” 开 步 执 行 任 务 


通过 CompletableFuture 提 供 的 进一步 封装 ， 我 们 很 容易 实现 Future 
模式 那样 的 异步 调用 。 比 如 : 


01 public static Integer calc(Integer para) { 


02 try { 

03 // 模拟 一 个 长 时 间 的 执行 

04 Thread.sleep(1000); 

05 } catch (InterruptedException e) { 
06 } 

07 return para*para; 


09 
10 public static void main(String[] args) throws InterruptedExcep 


{ 


11 final CompletableFuture<Integer> future = 

12 CompletableFuture.supplyAsync(() -> calc(50)); 
13 System.out.printin(future.get()); 

14 } 


上 述 代 码 中 ， 第 11 一 12 行 使 用 CompletableFuture.supplyAsync(0) 方 法 
构造 一 个 CompletableFuture 实 例 ， 在 supplyAsync0 水 数 中 ， 它 会 在 一 个 
新 的 线程 中 ， 执 行 传 入 的 参数 。 在 这 里 ， 它 会 执行 calc0) 方 法 。 而 calc() 
方法 的 执行 可 能 是 比较 慢 的 ， 但 是 这 不 影响 CompletableFuture 实 例 的 构 
造 速度 ， 因 此 supplyAsync0O 会 立即 返回 ， 它 返回 的 CompletableFuture 对 
象 实 例 束 可 以 作为 这 次 调用 的 契约 ， 在 将 来 任何 场合 ， 用 于 获得 最 终 的 
计算 结果 。 代 码 第 13 行 ， 试 图 获得 calc0O 的 计算 结果 ， 如 果 当 前 计算 没 
有 完成 ， 则 调用 get() 方 法 的 线程 就 会 等 待 。 











在 CompletableFuture 中 ， 类 似 的 工厂 方法 有 以 下 儿 个 : 


static <U> CompletableFuture<U> supplyAsync(Supplier<U> suppl 
static <U> CompletableFuture<U> supplyAsync(Supplier<U> suppl 
static CompletableFuture<Void> runAsync(Runnable runnable); 


static CompletableFuture<Void> runAsync(Runnable runnable, Execu 


其 中 supplyAsync() 方 法 用 于 那些 需要 有 返回 值 的 场景 ， 比 如 计算 某 
个 数据 等 。 而 runAsync0) 方 法 用 于 没有 返回 值 的 场景 ， 比 如 ， 仅 仅 是 简 
单 地 执行 某 一 个 异步 动作 。 


在 这 两 对 方法 中 ， 都 有 一 个 方法 可 以 接收 一 个 Executor 人 参数 。 这 束 
使 我 们 可 以 让 Supplier <U>> 或 者 Runnable 在 指定 的 线程 池 中 工作 。 如 果 
不 指定 ， 则 在 默认 的 系统 公共 的 ForkJoinPool.common 线 程 池 中 执行 。 


注意 : 在 Java 8 中 ， 新 增 了 ForkJoinPool1. commonPool () 方法 。 它 
可 以 获得 一 个 公共 的 ForkJoin 线 程 池 。 这 个 公共 线程 池 中 的 所 有 线 
程 都 是 Daemon 线 程 。 这 意味 着 如 果 主 线程 退出 ， 这 些 线程 无 论 是 否 
执行 完毕 ， 都 会 退出 系统 。 


6.5.3” 流 式 调 用 
在 前 文中 我 已 经 简单 的 提 到 ，CompletionStage 的 约 40 个 接口 是 为 函 


数 式 编 程 做 准备 的 。 在 这 里 ， 就 让 我 们 看 一 下 ， 如 何 使 用 这 些 接口 进行 
函数 式 的 流 式 API 调 用 : 


01 public static Integer calc(Integer para) { 


02 try { 

03 // 模拟 一 个 长 时 间 的 执行 

04 Thread.sleep(1000); 

05 } catch (InterruptedException e) { 
06 } 

07 return para*para; 

08 } 

09 


10 public static void main(String[] args) throws InterruptedExcep 


11 CompletableFuture<Void> fu=CompletableFuture.supplyAsync ( 


12 . thenApply((i)->Integer.toString(1) ) 


13 .thenApply((str)->"\""4+strt"\"") 
14 .thenAccept(System.out::printin); 
i5 fu.get(); 

16 } 


上 述 代码 中 ， 使 用 supplyAsyncO 函 数 执行 一 个 异步 任务 。 接 着 连续 
使 用 流 式 调用 对 任务 的 处 理 结果 进行 再 加 工 ， 直 到 最 后 的 结果 输出 。 


这 里 ， 我 们 在 第 15 行 执行 CompletableFuture.get(0) 方 法 ， 目 的 是 等 待 
calc0 函 数 执行 完成 。 如 果 不 进 行 这 个 等 竺 调用， 由 于 CompletableFuture 
异步 执行 的 缘故 ， 主 函数 不 等 calc(0) 方 法 执行 完毕 就 会 退出 ， 随 着 主线 
程 的 结束 ， 所 有 的 Daemon 线 程 都 会 立即 退出 ， 从 而 导致 calc0) 方 法 无 法 
正常 完成 。 


6.5.4 ”CompletableFuture 中 的 异常 处 
理 


如 果 CompletableFuture 在 执行 过 程 中 过 到 异常 ， 我 们 可 以 用 函数 式 
编程 的 风格 来 优雅 地 处 理 这 些 异 常 。CompletableFuture 提 供 了 一 个 异 各 
处 理 方 法 exceptionally0): 


01 public static Integer calc(Integer para) { 


02 return para / 0; 


05 public static void main(String[] args) throws InterruptedExcep 


06 CompletableFuture<Void> fu = CompletableFuture 


07 .supplyAsync(() -> calc(50)) 

08 .exceptionally(ex -> { 

09 System.out.println(ex.toString()); 
10 return 0; 

11 }) 

12 .thenApply((i) -> Integer.toString(i)) 
13 .thenApply( (str) -> "\"" + str + "\"") 
14 .thenAccept(System.out::printin); 

15 fu.get(); 

16 } 


在 上 述 代 码 中 ， 第 8 行 对 当前 的 CompletableFuture 进 行 异常 处 理 。 
如 果 没 有 异常 发 生 ， 则 CompletableFuture 就 会 返回 原 有 的 结果 。 如 果 遇 
到 了 异常 ， 就 可 以 在 exceptionally0) 中 人 处理 异常 ， 并 返回 一 个 默认 的 值 。 
在 上 例 中 ， 我 们 忽略 了 异常 堆栈 ， 只 是 简 蛙 地 打印 异常 的 信息 。 


执行 上 述 函 数 ， 我 们 将 得 到 输出 : 


java.util.concurrent.CompletionException: java.lang.ArithmeticExc 


Wo" 


6.5.5 组合 多 个 CompletableFuture 


CompletableFuture 还 允许 你 将 多 个 CompletableFuture 进 行 组 合 。 一 
种 方法 是 使 用 thenCompose()， 它 的 签名 如 下 : 


public <U> CompletableFuture<U> thenCompose(Function<? super T 


CompletionStage<U>> fn) 


一 个 CompletableFuture 可 以 在 执行 完成 后 ， 将 执行 结果 通过 
Function 传 递 给 下 一 个 CompletionStage 进 行 处 理 〈Function 接 口 返 回 新 的 
CompletionStage 实 例 ) : 


01 public static Integer calc(Integer para) { 
02 return para/2; 

03 } 

04 


05 public static void main(String[] args) throws InterruptedExcep 


06 CompletableFuture<Void> fu = 

07 CompletableFuture.supplyAsync(() -> calc(50)) 

08 . thenCompose( (i)->CompletableFuture.supplyAsync( (` 
09 .thenApply((str)->"\"" + str + "\"").thenAccept (S) 
10 fu.get(); 

11 } 


上 述 代码 第 8 行 ， 将 处 理 后 的 结果 传递 给 thenCompose()， 并 进一步 
传递 给 后 续 新 生成 的 CompletableFuture 实 例 。 以 上 代码 的 输出 如 下 : 


" 12 " 


另外 一 种 组 合 多 个 CompletableFuture 的 方法 是 thenCombine0， 它 的 
签名 如 下 : 


public <U,V> CompletableFuture<V> thenCombine 


(CompletionStage<? extends U> other, 


BiFunction<? super T,? super U,? extends V> fn) 





方法 thenCombine(O) 首 先 完 成 当前 CompletableFuture 和 other 的 执行 。 
接着 ， 将 这 两 者 的 执行 结果 传递 给 BiFunction〔 该 接口 接收 两 个 参数 ， 
并 有 一 个 返回 值 ) ， 并 返回 代表 BiFunction 实 例 的 CompletableFuture 对 
象 : 


01 public static Integer calc(Integer para) { 
02 return para / 2; 

03 } 

04 


05 public static void main(String[] args) throws InterruptedExcep 


06 CompletableFuture<Integer> intFuture = CompletableFuture. 
07 CompletableFuture<Integer> intFuture2 = CompletableFuture 
08 

09 CompletableFuture<Void> fu = intFuture.thenCombinet(intFu 
10 -thenApply((str)i > SEN) 

11 .thenAccept(System.out::printlin); 

12 fu.get(); 

13 } 


上 述 代 码 中 ， 首 先生 成 两 个 CompletableFuture 实 例 〈 第 6 一 7 行 ) ， 
接着 使 用 thenCombine() 组 合 这 两 个 CompletableFuture， 将 两 者 的 执行 结 
末 进 行 累加 (由 第 9 行 的 Gi, j -> (+ SEHD . IPRA RIN RAS 
符 串 ， 并 输出 。 上 述 代码 的 输出 是 : 


Ae As 


6.6 


谈 写 锁 的 改进 : StampedLock 


StampedLock 是 Java 8 中 引入 的 一 种 新 的 锁 机 制 。 简 单 的 理解 ， 可 以 
认为 它 是 读 写 锁 的 一 个 改进 版 本 。 读 写 锁 虽然 分 离 了 读 和 写 的 功能 ， 使 
得 读 与 读 之 间 可 以 完全 并 发 。 但 是 ， 读 和 写 之 间 依 然 是 冲突 的 。 读 锁 会 
完全 阻塞 写 锁 ， 它 使 用 的 依然 是 悲观 的 锁 策 略 ， 如 果 有 大 量 的 读 线程 ， 





它 也 有 可 能 引起 写 线程 的 “饥饿 ”。 


而 StampedLock 则 提供 了 一 种 乐观 的 读 策略 。 这 种 乐观 的 锁 非 常 类 
似 无 锁 的 操作 ， 使 得 乐观 锁 完 全 不 会 阻 豆 写 线程 。 


6.6.1 StampedLock 使 用 示例 


StampedLock 的 使 用 并 不 困难 ， 下 面 是 StampedLock 的 使 用 示例 : 


01 public class Point { 


02 
03 
04 
05 
06 
07 
08 
09 
10 


private double x, y; 


private final StampedLock sl = new StampedLock(); 


void move(double deltaX, double deltaY) { 
long stamp = sl.writeLock(); 
try { 
x += deltax; 
y += deltaY; 
} finally { 


// 这 是 - 


alal sl.unlockwrite(stamp); 





12 } 

13 } 

14 

15 double distanceFromOrigin() { // ABATE 
16 long stamp = sl.tryOptimisticRead(); 

17 double currentX = x, currentY = y; 

18 if (!sl.validate(stamp)) { 

19 stamp = sl.readLock(); 

20 try { 

21 currentX = x; 

22 currentyY = y; 

23 } finally { 

24 sl.unlockRead(stamp); 

25 } 

26 } 

27 return Math.sqrt(currentX * currentX + currentY * curr 
28 } 

29 } 


上 述 代 人 码 出 自 JDK 的 官方 文档 。 它 定义 了 一 个 点 Point 类 ， 内 部 有 两 
个 元 素 x 和 y， 表 示 点 的 坐标 。 第 3 行 ， 定 义 了 StampedLock 锁 。 第 15 行 定 
义 的 distanceFromOrigin() 方 法 是 一 个 只 读 方法 ， 它 只 会 读 取 Point 的 x 和 y 
坐标 。 在 读 取 时 ， 首 先 使 用 了 StampedLock.tryOptimisticRead() 方 法 。 这 
个 方法 表示 试图 党 试 一 次 乐观 读 。 它 会 返回 一 个 类 似 于 时 间 惟 的 邮 惟 整 
数 stamp。 这 个 stamp 就 可 以 作为 这 一 次 锁 获 取 的 凭证 。 





接着 ， 在 第 17 行 ， 读 取 x 和 y 的 值 。 当 然 ， 这 时 我 们 并 不 确定 这 个 x 
和 y 是 否 是 一 致 的 《在读 取 x 的 时 候 ， 可 能 其 他 线程 改写 了 y 的 值 ， 使 得 
currentX 和 currentY 处 于 不 一 致 的 状态 ) ， 因 此 ， 我 们 必须 在 第 18 行 ， 使 
用 validate(0) 方 法 ， 判 断 这 个 stamp 是 人 否 在 读 过 程 发 生 期 间 被 修改 过 。 如 
果 stamp 没 有 被 修改 过 ， 则 认为 这 次 读 取 是 有 效 的 ， 因 此 就 可 以 跳 转 到 
第 27 行 ， 进 行 数据 处 理 。 反 之 ， 如 果 stamp 是 不 可 用 的 ， 则 意味 大 在读 
取 的 过 程 中 ， 可 能 被 其 他 线程 改写 了 数据 ， 因 此 ， 有 可 能 出 现 了 脏 读 。 
如 果 出 现 这 种 情况 ， 我 们 可 以 像 处 理 CAS 操 作 那 样 在 一 个 死 循 环 中 一 直 
使 用 乐观 读 ， 直 到 成 功 为 止 。 





也 可 以 升级 锁 的 级 别 。 在 本 例 中 ， 我 们 升级 乐观 锁 的 级 别 ， 将 乐观 
锁 变 为 悲观 锁 。 在 第 19 行 ， 当 判断 乐观 读 失 败 后 ， 使 用 readLock() 获 得 
莫 观 的 读 锁 ， 并 进一步 读 取 数 据 。 如 果 当 前 对 象 正 在 被 修改 ， 则 读 锁 的 
申请 可 能 导致 线程 挂 起 。 


写 入 的 情况 可 以 参考 第 5 行 定义 的 move0 函 数 。 使 用 writeLock() 函 数 
可 以 申请 写 锁 。 这 里 的 含义 和 读 写 锁 是 类 似 的 。 





在 退出 临界 区 时 ， 不 要 瑟 记 释放 写 锁 《第 11 行 ) 或 者 读 锁 (第 24 
行 ) 。 


可 以 看 到 ，StampedLock 通 过 引入 乐观 读 来 增加 系统 的 并 行 度 。 


6.6.2 ”StampedLock 的 小 陷阱 


StampedLock 内 部 实现 时 ， 使 用 类 似 于 CAS 操 作 的 死 循环 反复 尝试 
的 策略 。 在 它 挂 起 线程 时 ， 使 用 的 是 Unsafe.park() 函 数 ， 而 park() 函 数 在 


过 到 线程 中 断 时 ， 会 直接 返回 注音， 不 同 于 Thread.sleep()， 它 不 会 抛 
HÆ) 。 而 在 StampedLock 的 死 循环 逻辑 中 ， 没 有 处 理 有 关中 断 的 多 
辑 。 因 此 ， 这 就 会 导致 阻塞 在 park0 上 的 线程 被 中 断后 ， 会 再 次 进入 循 
环 。 而 当 退 出 条 件 得 不 到 满足 时 ， 就 会 发 生 饮 狂 占用 CPU 的 情况 。 这 一 
点 值得 我 们 注意 ， 下 面 演 示 了 这 个 问题 : 








01 public class StampedLockCPUDemo { 


02 static Thread[] holdCpuThreads = new Thread[3]; 

03 static final StampedLock lock = new StampedLock(); 

04 public static void main(String[] args) throws InterruptedE 
05 new Thread() { 

06 public void run() { 

07 long readLong = lock.writeLock(); 

08 LockSupport .parkNanos (600000000000L); 

09 lock.unlockwrite(readLong); 

10 } 

11 }.start(); 

12 Thread.sleep(100) ; 

13 ror (ame 0 

14 holdCpuThreads[i] = new Thread(new HoldCPUReadThre 
5 holdCpuThreads[i].start(); 

16 } 

17 Thread.sleep(10000); 

18 // 线 程 中 断后 ， 会 占用 CPU 

19 ror (ame L = 05 see mL) 4 

20 holdCpuThreads[i].interrupt(); 


Bat } 


23 

24 private static class HoldCPUReadThread implements Runnable 
25 public void run() { 

26 long lockr = lock.readLock(); 

27 System.out.printin(Thread.currentThread().getName( 
28 lock.unlockRead(lockr); 

29 } 

30 } 

31 } 


在 上 述 代码 中 ， 首 先 开 启 线程 占用 写 锁 (第 7 行 )， 注 意 ， 为 了 演 
示 效 果 ， 这 里 使 写 线程 不 释放 锁 而 一 直 等 等 。 接 着 ， 开 局 3 个 读 线程 ， 
让 筷 们 请 求 读 锁 。 此 时 ， 由 于 写 锁 的 存在 ， 所 有 读 线 程 都 会 被 最 终 
起 。 


下 面 是 其 中 一 个 读 线程 在 挂 起 时 的 信息 : 


"Thread-2" #10 prio=5 os_prio=0 tid=0x14b1d800 nid=Oxafc waiting 
java.lang.Thread.State: WAITING (parking) 
at sun.misc.Unsafe.park(Native Method) 
- parking to wait for <0x046b54c8> (a java.util.concurr 
at java.util.concurrent.locks.StampedLock.acquireRead(Sta 
at java.util.concurrent.locks.StampedLock.readLock(Stampe 
at geym.conc.ch6.stamped.StampedLockCPUDemo$HoldCPUReadTh 
(StampedLockCPUDemo. java: 35) 


at java.lang.Thread.run(Thread. java: 745) 


可 以 看 到 ， 这 个 线程 因为 park() 的 操作 而 进入 了 等 待 状态 ， 这 种 情 
况 是 正常 的 。 





而 在 10 秒 以 后 (代码 第 17 行 执行 了 10 秒 等 每 )， 系 统 中 断 了 这 3 个 
读 线程 ， 之 后 ， 你 就 会 发 现 ， 你 的 CPU 占 用 率 极 有 可 能 会 问 升 。 这 是 因 








为 中 断 导 致 park() 函 数 返 回 ， 使 线程 再 次 进入 运行 状态 ， 下 面 是 同一 个 
线程 在 中 断后 的 信息 : 





"Thread-2" #10 prio=5 os_prio=0 tid=0x14b1d800 nid=Oxafc runnable 
java.lang.Thread.State: RUNNABLE 
at sun.misc.Unsafe.park(Native Method) 
- parking to wait for <0x046b54c8> (a java.util.concurr 
at java.util.concurrent.locks.StampedLock.acquireRead(Sta 
at java.util.concurrent.locks.StampedLock.readLock(Stampe 
at geym.conc.ch6.stamped.StampedLockCPUDemo$HoldCPUReadTh 
(StampedLockCPUDemo. java: 35) 


at java.lang.Thread.run(Thread. java: 745) 


此 时 ， 这 个 线程 的 状态 是 RUNNABLE， 这 是 我 们 不 愿意 看 到 的 。 
它 会 一 直 存 在 并 耗 尽 CPU 资源 ， 直 到 目 己 抢占 到 了 锁 。 





6.6.3 有关 StampedLock 的 实现 思想 








StampedLock 的 内 部 实现 是 基于 CLH 锁 的 。CLH 锁 是 一 种 自 旋 锁 ， 
它 保证 没有 饥饿 发 生 ， 并 且 可 以 保证 FIFO (First-In-First-Out) 的 服务 顺 
序 。 


CLH 锁 的 基本 思想 如 下 : 锁 维 护 一 个 等 待 线程 队列 ， 所 有 申请 锁 ， 
但 是 没有 成 功 的 线程 都 记录 在 这 个 队列 中 。 每 一 个 节点 〈 一 个 节点 代表 
一 个 线程 )》 ， 保 存 一 个 标记 位 〈locked) ， 用 于 判断 当前 线程 是 否 已 经 
释放 锁 。 


当 一 个 线程 试图 获得 锁 时 ， 取 得 当前 等 竺 队列 的 尾部 节点 作为 其 前 
序 节 点 ， 并 使 用 类 似 如 下 代码 判断 前 序 节 点 是 否 已 经 成 功 释放 锁 : 
while (pred.locked) { 

i 





只 要 前 序 节 点 Cpred) 没有 释放 锁 ， 则 表示 当前 线程 还 不 能 继续 执 
行 ， 因 此 会 自 旋 等 待 。 


有 反之， 如 果 前 序 线程 已 经 释放 锁 ， 则 当前 线程 可 以 继续 执行 。 


释放 锁 时 ， 也 遵循 这 个 逻辑 ， 线 程 会 将 自身 节点 的 locked 位 置 标 记 
为 false， 那 么 后 续 等 待 的 线程 就 能 继续 执行 了 。 





如 图 6.4 所 示 ， 显 示 了 CLH 队 列 锁 的 基本 思想 。 
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图 6-4 ”CLH 队 列 锁 


— 








StampedLock 正 是 基于 这 种 思想 ， 但 是 实现 上 更 为 复杂 。 








在 StampedLock 内 部 ， 会 维护 一 个 等 待 链表 队列 ; 


01 /** Wait nodes */ 


02 static final class WNode { 


03 volatile WNode prev; 

04 volatile WNode next; 

05 volatile WNode cowait; // 读 节 点 链表 

06 volatile Thread thread; // 当 可 能 被 暂停 时 非 空 

07 volatile int status; // ©, WAITING, or CANCELLED 
08 final int mode; // RMODE or WMODE 

09 WNode(int m, WNode p) { mode = m; prev = p; } 

10 } 

11 


12 /** CLH 队列 头 部 */ 
13 private transient volatile WNode whead; 
14 /** CLH 队列 尾部 */ 


15 private transient volatile WNode wtail; 











上 述 代 码 中 ，WNode 为 链表 的 基本 元 素 ， 每 一 个 WNode 表 示 一 个 
等 待 线程 。 字 段 whead 和 wtail 分 别 指 回 等 竺 链表 的 头 部 和 尾部 。 


另外 一 个 重要 的 字段 为 state: 


private transient volatile long state; 





字段 state 表 示 当 前 锁 的 状态 。 它 是 一 个 long 型 ， 有 64 位 ， 其 中 ， 倒 
数 第 8 位 表示 写 锁 状 态 ， 如 果 该 位 为 1， 表 示 当 前 由 写 锁 占 用 。 





对 于 一 次 乐观 读 的 操作 ， 它 会 执行 如 下 操作 : 


public long tryOptimisticRead() { 
long s; 


return (((s = state) & WBIT) == OL) ? (s & SBITS) : OL; 


一 次 成 功 的 乐观 读 必须 保证 当前 锁 没 有 写 锁 占 用 。 其 中 WBIT 用 来 
获取 写 锁 状态 位 ， 值 为 0x580。 如 宁 成 功 ， 则 返回 当前 state 的 值 〈 末 尾 7 
位 清 零 ， 末 尾 7 位 表示 当前 正在 读 取 的 线程 数量 ) 。 





如 果 在 乐观 读 后 ， 有 线程 申请 了 写 锁 ， 那 么 state 的 状态 就 会 改变 : 


1 public long writeLock() { 

2 long s, next; // bypass acquireWrite in fully unlocked cas 
3 return ((((s = state) & ABITS) == OL && 

4 U.compareAndSwapLong(this, STATE, s, next = s + WB 
5 next : acquireWrite(false, OL)); 

6 } 


上 述 代码 中 第 4 行 ， 设 置 写 锁 位 为 1 (通过 加 上 WBIT (0x80) ) 。 
这 样 ， 就 会 改变 state 的 取 值 。 那 么 在 乐观 锁 确认 (validate) IT, WER 
现 这 个 改动 ， 而 导致 乐观 锁 失 效 。 


public boolean validate(long stamp) { 
U.loadFence()j; 


return (stamp & SBITS) == (state & SBITS); 


上 述 validateO 函 数 比 较 当 前 stamp 和 发 生 乐 观 锁 时 取得 的 stamp， 如 
果 不 一 致 ， 则 宣告 乐观 锁 失 败 。 


乐观 锁 失 败 后 ， 则 可 以 提升 锁 级 别 ， 使 用 莫 观 读 锁 。 


1 public long readLock() { 

2 long s = state, next; // bypass acquireRead on common unco 
3 return ((whead == wtail && (s & ABITS) < RFULL && 

4 U.compareAndSwapLong(this, STATE, s, next = s + RU 
5 next : acquireRead(false, OL)); 

6 } 


严 观 读 会 尝试 设置 state 状 态 ( 第 4 行 )， 它 会 将 state 加 1 前 提 是 读 
线程 数量 没有 溢出 ， 对 于 读 线 程 数量 洪 出 的 情况 ， 会 使 用 辅助 的 
readerOverflow 进 行 统计 ， 我 们 在 这 里 不 做 过 于 烦琐 的 讨论 ) ， 用 于 统 
计 读 线程 的 数量 。 如 果 失 败 ， 则 进入 acquireRead0 二 次 尝试 锁 获取 。 





在 acquireRead0 中 ， 线 程 会 在 不 同 条 件 下 进行 徊 干 次 自 旋 ， 试 图 通 
过 CAS 操 作 获 得 锁 。 如 采 上 自 旋 宣 告 失败 ， 则 会 局 用 CLH 队 列 ， 将 自己 加 
到 队列 中 。 之 后 再 进行 自 旋 ， 如 果 发 现 自己 成 功 获得 了 读 锁 ， 则 会 进 一 
步 把 自己 cowait 队 列 中 的 读 线 程 全 部 激活 (使 用 Unsafe.unpark() 方 法 ) 。 
如 采 最 终 依然 无 法 成 功 获得 读 锁 ， 则 会 使 用 Unsafe.park(0) 方 法 挂 起 当前 
线程 。 


方法 acquireWrite0 和 acquireRead0O 也 非常 类 似 ， 也 是 通过 自 旋 党 
试 、 加 入 等 待 队 列 、 直 至 最 终 Unsafe.parkO0 挂 起 线程 的 逻辑 进行 的 。 释 
放 锁 时 与 加 锁 动 作 相 反 ， 以 unlockWrite() 为 例 : 


1 public void unlockWrite(long stamp) { 
2 WNode h; 
3 if (state != stamp || (stamp & WBIT) == OL) 


4 throw new IllegalMonitorStateException(); 

5 state = (stamp += WBIT) == OL ? ORIGIN : stamp; 
6 if ((h = whead) != null && h.status != 0) 

7 release(h); 

8 } 
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接着 ， 如 采 等 待 队 列 不 为 空 ， 则 从 等 待 队列 中 激活 一 个 线程 〈 绝 大 
部 分 情况 下 是 第 1 个 等 待 线程 ) 继续 执行 《第 7 行 ) 。 


6.7 原子 类 的 增强 


在 之 前 的 章节 中 己 经 提 到 了 原子 类 的 使 用 ， 无 锁 的 原子 类 操作 使 用 
系统 的 CAS 指 令 ， 有 着 远 远 超越 锁 的 性 能 。 那 是 否 有 可 能 在 性 能 上 更 上 
一 层 楼 呢 ?” 答 案 是 肯定 的 。 在 Java 8 中 引入 了 LongAdder 类 ， 这 个 类 也 在 
java.util.concurrent.atomic 包 下 ， 因 此 ， 可 以 推测 ， 它 也 是 使 用 了 CAS 指 


令 。 


6.7.1 更 快 的 原子 类 : LongAdder 


大 家 对 AtomicInteger 的 基本 实现 机 制 应 该 比较 了 解 。 它 们 都 是 在 一 
个 死 循环 内 ， 不 断 党 试 修 改 目 标 值 ， 直 到 修改 成 功 。 如 果 竞 争 不 激烈， 
那么 修改 成 功 的 概率 束 很 高 ， 人 否则， 修改 失败 的 概率 就 很 高 。 在 大 量 修 
改 失败 时 ， 这 些 原子 操作 就 会 进行 多 次 循环 答 试 ， 因 此 性 能 就 会 受到 影 
啊 。 








那么 当 竞 争 激烈 的 时 候 ， 我 们 应 该 如 何 进 一 步 提 高 系统 的 性 能 呢 ? 
一 种 基本 方案 就 是 可 以 使 用 热点 分 离 ， 将 竞争 的 数据 进行 分 解 ， 基 于 这 
个 思路 ， 大 家 应 该 可 以 想到 一 种 对 传统 AtomicInteger 等 原子 类 的 改进 方 
法 。 虽 然 在 CAS 操 作 中 没有 锁 ， 但 是 像 减 小 锁 粒 度 这 种 分 离 热点 的 思想 
依然 可 以 使 用 。 一 种 可 行 的 方案 束 是 仿造 ConcurrentHashMap， 将 热点 
数据 分 离 。 比 如 ， 可 以 将 AtomicInteger 的 内 部 核心 数据 value 分 离 成 一 个 
数组 ， 每 个 线程 访问 时 ， 通 过 哈 希 等 算法 映射 到 其 中 一 个 数字 进行 计 
数 ， 而 最 终 的 计数 结果 ， 则 为 这 个 数组 的 求 和 累加 ， 如 图 6.5 所 示 ， 显 
示 了 这 种 优化 思路 。 其 中 ， 热 点 数据 value 被 分 离 成 多 个 单元 cell， 每 个 





cell 独 目 维护 内 部 的 值 ， 当 前 对 象 的 实际 值 由 所 有 的 cell 味 计 合 成 ， 这 
样 ， 热 点 惑 进行 了 有 效 的 分 离 ， 提 高 了 并 行 度 。LongAdder 正 是 使 用 了 
这 种 思想 。 
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图 6.5 原子 类 的 优化 思路 


在 实际 的 操作 中 ，LongAdder 并 不 会 一 开始 就 动用 数组 进行 处 理 ， 
而 是 将 所 有 数据 都 先 记 录 在 一 个 称 为 base 的 变量 中 。 如 果 在 多 线程 条 件 
下， 大 家 修改 base 都 没有 冲突 ， 那 么 也 没有 必要 扩展 为 cell 数 组 。 但 
是 ， 一 旦 base 修 改 发 生 冲 突 ， 就 会 初始 化 cell 数 组 ， 使 用 新 的 策略 。 如 
果 使 用 cell 数 组 更 新 后 ， 发 现在 某 一 个 cell 上 的 更 新 依然 发 生 冲 突 ， 那 么 
系统 就 会 尝试 创建 新 的 cell， 或 者 将 cell 的 数量 加 倍 ， 以 减少 冲突 的 可 
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下 面 我 们 简单 分 析 一 下 increment( 方 法 《该 方法 会 将 LongAdder 自 
增 1) 的 内 部 实现 : 


01 public void increment() { 
02 add(1iL); 

03 } 

04 public void add(long x) { 


05 Cell[] as; long b, v; int m; Cell a; 


06 if ((as = cells) != null || !casBase(b = base, b + x)) { 
07 boolean uncontended = true; 

08 if (as == null || (m = as.length - 1) < © || 

09 (a = as[getProbe() & m]) == null || 

10 !(uncontended = a.cas(v = a.value, v + x))) 

lel longAccumulate(x, null, uncontended); 

12 } 

13 } 


它 的 核心 是 第 4 行 的 add0 方 法 。 最 开始 cells 为 nall， 因 此 数据 会 向 
base 增 加 《第 6 行 ) 。 但 是 如 果 对 base 的 操作 冲突 ， 则 会 进入 第 7 行 ， 并 
设置 冲突 标记 uncontended 为 tue。 接 着 ， 如 果 判 断 cells 数 组 不 可 用 ， 或 
者 当前 线程 对 应 的 cell 为 null， 则 直接 进入 longAccumulate() 方 法 。 否 则 
会 尝试 使 用 CAS 方 法 更 新 对 应 的 cell 数 据 ， 如 果 成 功 ， 则 退出 ， 失 败 则 
进入 longAccumulate() 方 法 。 


由 于 longAccumulate() 方 法 比较 复杂 ， 限 于 篇 幅 ， 这 里 不 再 展开 讨 
论 ， 其 大 致 内 容 是 根据 需要 创建 新 的 cell 或 者 对 cell 数 组 进行 扩容 ， 以 减 
少 冲 突 。 


下 面 ， 让 我 们 简单 地 对 LongAddr、 原 子 类 以 及 同步 锁 进行 性 能 测 
试 。 测 试 方法 是 使 用 多 个 线程 对 同一 个 整数 进行 系 加 ， 观 察 使 用 3 种 不 
同方 法 时 所 消耗 的 时 间 。 


首先 ， 我 们 定义 一 些 辅助 变量 : 


private static final int MAX_THREADS = 3; // 线 程 数 


private static final int TASK_COUNT = 3; // 任 务 数 
private static final int TARGET_COUNT = 10000000; // Ape 


private AtomicLong acount =new AtomicLong(OL); // 无 锁 的 上 
private LongAdder lacount=new LongAdder(); 


private long count=0; 


static CountDownLatch cdlsync=new CountDownLatch(TASK_COUNT) ; 
static CountDownLatch cdlatomic=new CountDownLatch(TASK_COUNT ) ; 


static CountDownLatch cdladdr=new CountDownLatch(TASK_COUNT) ; 








上 述 代码 中 ， 指 定 了 测试 线程 数量 、 目 标 总 数 以 及 3 个 初始 值 为 0 的 
整 型 变量 acount、lacount 和 count。 它 们 分 别 表 示 使 用 AtomicLong、 
LongAdder 和 锁 进行 同步 时 的 操作 对 象 。 





下 面 是 使 用 同步 锁 时 的 测试 代码 : 


01 protected synchronized long inc(){ // 有 锁 的 
02 return ++count; 

03 } 

04 

05 protected synchronized long getCount(){ // 有 锁 的 
06 return count; 

07 } 

08 

09 

10 public class SyncThread implements Runnable{ 


ala protected String name; 


12 
13 
14 
15 
16 
17 
18 
19 
20 
24 
22 
23 
24 
25 
26 
21 
28 
29 
30 
31 
32 
33 
34 
35 
36 
37 
38 


protected long starttime; 
LongAdderDemo out; 
public SyncThread(LongAdderDemo o,long starttime){ 
out=0; 
this.starttime=starttime; 
} 
@Override 
public void run() { 
long v=out.getCount(); 
while(v<TARGET_COUNT) { // 在 到 达 | 
v=out.inc(); 
} 
long endtime=System.currentTimeMillis(); 
System.out.println("SyncThread spend:"+(endtime-startt 


cdlsync.countDown( ); 


public void testSync() throws InterruptedException{ 


ExecutorService exe=Executors.newFixedThreadPool (MAX_THREA 
long starttime=System.currentTimeMillis(); 
SyncThread sync=new SyncThread(this, starttime) ; 
for(int 1=0;1<TASK_COUNT;1i++) { 

exe. submit(sync); // 提 交 线 
} 
cdlsync.await(); 


exe. shutdown(); 


39 


J; 


上 述 代码 第 10 行 ， 定 义 线程 SyncThread， 它 使 用 加 锁 方式 增加 count 


的 值 。 在 第 30 行 定义 的 testSync0 方 法 中 ， 使 用 线程 池 控制 多 线程 进行 于 
加 操作 。 


01 
02 
03 
04 
05 
06 
07 
08 
09 
10 
11 
12 
13 
14 
15 
16 
I 
18 
19 
20 





使 用 类 似 的 方法 实现 原子 类 累加 计时 统计 : 


public class AtomicThread implements Runnable{ 

protected String name; 

protected long starttime; 

public AtomicThread(long starttime) { 
this.starttime=starttime; 

} 

@Override 

public void run() { // 在 : 
long v=acount.get(); 
while(v<TARGET_COUNT) { 

v=acount.incrementAndGet (); // 无 人 

} 
long endtime=System.currentTimeMillis(); 
System.out.println("AtomicThread spend:"+(endtime-star 


cdlatomic.countDown(); 


public void testAtomic() throws InterruptedException{ 


ExecutorService exe=Executors.newFixedThreadPool (MAX_THREA 


21 
22 
23 
24 
25 
26 
27 
28 


long starttime=System.currentTimeMillis(); 
AtomicThread atomic=new AtomicThread(starttime) ; 
for(int 1=0;1<TASK_COUNT;1i++) { 
exe. submit(atomic); // 提 : 
cdlatomic.await(); 


exe.shutdown(); 


同 理 ， 以 下 代码 使 用 LongAddr 实 现 类 似 的 功能 : 


01 public class LongAddrThread implements Runnable{ 


02 
03 
04 
05 
06 
07 
08 
09 
10 
11 
12 
13 
14 
15 
16 


protected String name; 
protected long starttime; 
public LongAddrThread(long starttime){ 
this.starttime=starttime; 
} 
@Override 
public void run() { 
long v=lacount.sum(); 
while(v<TARGET_COUNT) { 
lacount.increment(); 
v=lacount.sum(); 
} 
long endtime=System.currentTimeMillis(); 
System.out.println("LongAdder spend:"+(endtime-startti 


cdladdr.countDown(); 


dig } 
18 } 
19 


20 public void testAtomicLong() throws InterruptedException{ 


21 ExecutorService exe=Executors.newFixedThreadPool (MAX_THREA 
22 long starttime=System.currentTimeMillis(); 

23 LongAddrThread atomic=new LongAddrThread(starttime) ; 

24 for(int 1=0;i1<TASK_COUNT; i++) { 

25 exe. submit (atomic); // 提 : 
26 } 

27 cdladdr.await(); 

28 exe. shutdown(); 

29 } 


注意 ， 由 于 LongAddr 中 ， 将 单个 数值 分 解 为 多 个 不 同 的 段 。 因 此 ， 
在 进行 累加 后 ， 上 述 代码 中 第 11 行 的 pcrementO 函 数 并 不 能 返回 当前 的 
数值 。 要 取得 当前 的 实际 值 ， 需 要 使 用 第 12 行 的 sum() 函 数 重新 计算 。 
这 个 计算 是 需要 有 额外 的 成 本 的 ， 但 即使 加 上 这 个 额外 成 本 ，LongAddr 
的 表现 还 是 比 AtomicLong 要 好 。 





执行 这 些 代 码 ， 就 可 以 得 到 锁 、 原 子 类 和 LongAddr 三 者 的 性 能 比较 
数据 ， 如 下 所 示 : 


SyncThread spend:1784ms v=10000002 
SyncThread spend:1784ms v=10000000 
SyncThread spend:1784ms v=10000001 
AtomicThread spend:695ms v=10000001 
AtomicThread spend:695ms v=10000000 


AtomicThread spend:695ms v=10000002 
LongAdder spend:227ms v=10000002 
LongAdder spend:227ms v=10000002 
LongAdder spend:227ms v=10000002 





可 以 看 到 ， 就 计数 性 能 而 言 ，LongAdder 已 经 超越 了 普通 的 原子 操 
作 了 。 其 中 ， 锁 操作 耗 时 约 1784ms， 普 通 原 子 操作 耗 时 约 695ms， 而 
LongAddr 仅 需要 227ms 左 右 。 


LongAddr 的 另外 一 个 优化 手段 是 避免 了 伪 共 享 。 大 家 可 以 先 回 顾 一 
下 第 5 章 中 有 关 伪 共享 的 问题 。 但 是 ， 需 要 注意 的 是 ，LongAddr 中 并 不 
是 直接 使 用 padding 这 种 看 起 来 比较 碍 眼 的 做 法 ， 而 是 引入 了 一 种 新 的 


注释 “@sun.misc.Contended”。 











对 于 LongAddr 中 的 每 一 个 Cell， 它 的 定义 如 下 所 示 : 


@sun.misc.Contended 
static final class Cell { 
volatile long value; 
Cell(long x) { value = x; } 
final boolean cas(long cmp, long val) { 
return UNSAFE.compareAndSwapLong(this, valueOffset, cmp, 
} 
省 略 其 他 不 必要 的 信息 





可 以 看 到 ， 在 上 述 代 码 第 1 行 申 明了 Cell 类 为 sun.misc.Contended。 
这 将 会 使 得 Java 虚 拟 机 目 动 为 Cell 解 决 伪 共 享 问题 。 


当然 ， 在 我 们 自己 的 代码 中 也 可 以 使 用 sun.misc.Contended 来 解决 伪 


共享 问题 ， 但 是 需要 额外 使 用 虚拟 机 参数 -XX:-RestrictContended， 奉 
则 ， 这 个 注释 将 被 忽略 。 











大 家 应 该 还 记得 第 5 章 中 有 关 伪 共享 的 案例 吧 ! 限于 篇 幅 ， 这 里 不 
再 贴 出 完整 代码 ， 只 给 出 关键 部 分 的 改动 。 我 们 将 VolatileLong 修 改 如 
下 : 


@sun.misc.Contended 
public final static class VolatileLong { 


public volatile long value = OL; 


在 这 里 ， 我 们 去 除了 那些 看 起 来 不 太 雅 观 的 padding， 同 时 增加 了 
sun.misc.Contended 申 明 ， 这 个 就 告诉 虚拟 机 我 们 希望 在 这 个 类 上 解决 伪 
共享 问题 。 然 后 ， 我 们 就 可 以 测试 这 段 代 码 了 。 当 然 了 ， 和 干 万 不 要 起 记 

旨 定 虚拟 机 参数 -XX:-RestrictContended， 人 和 否则， 你 的 这 个 优化 将 被 无 
视 。 





跑 一 下 优化 后 的 程序 ， 是 不 是 比 传统 的 方式 快 很 多 呢 ? 


6.7.2 ”LongAdder 的 功能 增强 版 : 
LongAccumulator 





LongAccumulator 是 LongAdder 的 杀 兄 弟 ， 它 们 有 公共 的 父 类 
Striped64。 因 此 ，LongAccumulator 内 部 的 优化 方式 和 LongAdder 是 一 样 
的 。 它 们 都 将 一 个 long 型 整数 进行 分 制 ， 存 储 在 不 同 的 变量 中 ， 以 防止 
多 线程 竞争 。 两 者 的 主要 人 逻辑 是 类 似 的， 但 是 LongAccumulator 是 











LongAdder 的 功能 扩展 ， 对 于 LongAdder 来 说 ， 它 只 是 每 次 对 给 定 的 整 
数 执 行 一 次 加 法 ， 而 LongAccumulator 则 可 以 实现 任意 函数 操作 。 


可 以 使 用 下 面 的 构造 函数 创建 一 个 LongAccumulator 实 例 : 


public LongAccumulator(LongBinaryOperator accumulatorFunction, lon 


第 1 个 参数 accumulatorFunction 束 是 需要 执行 的 二 元 函数 (接收 两 个 
long 形 参数 并 返回 long) ， 第 2 个 参数 是 初始 值 。 





下 面 这 个 例子 展示 了 LongAccumulator 的 使 用 ， 它 将 通过 多 线程 访 
问 若 干 个 整数 ， 并 返回 过 到 的 最 大 的 那个 数字 。 


01 public static void main(String[] args) throws Exception { 


02 LongAccumulator accumulator = new LongAccumulator(Long::ma 
03 Thread[] ts = new Thread[1000]; 

04 

05 for (int i = 0; i < 1000; i++) { 

06 ts[i] = new Thread(() -> { 

07 Random random = new Random(); 
08 long value = random.nextLong(); 
09 accumulator .accumulate(value) ; 
10 }); 

11 ts[i].start(); 

12 } 

13 ror (Gint L = ®©; 1 < 1000; 1r) f 

14 ts[i].join(); 


15 } 


16 System.out.println(accumulator.longValue()); 


tie 


上 述 代码 第 2 行 ， 构 造 了 LongAccumulator 实 例 。 因 为 我 们 要 过 滤 最 
大 值 ， 因 此 传 入 Long::max 函 数 句柄 。 汝 有 数据 通过 accumulate() 方 法 传 
入 LongAccumulator 后 〈 第 9 行 ) ，LongAccumulator 会 通过 Long::max 识 
别 最 大 值 并 且 保 存在 内 部 (很 可 能 是 cell 数 组 内 ， 也 可 能 是 base〉。 在 
代码 第 16 行 ， 通 过 longValue() 函 数 对 所 有 的 cell 进 行 Long::max 操 作 ， 得 
到 最 大 值 。 
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o http://feed.hjue.me/articles/detail/2014-07-10/364485/cpu-bug- 


concurrency 
。 CLH 自 旋 锁 和 其 他 自 旋 锁 的 详细 介绍 

o «The Art of Multiprocessor Programming) 
e JDK 8P KIRE [Hl ell 


o http://www.programering.com/a/MDM5IzNwAT¢g.html 


第 7 章 ”使 用 Akka 构 建 高 并 发 程序 





我 们 知道 ， 写 出 一 个 正确 的 、 高 性 能 并 且 可 扩展 的 并 发 程序 是 相当 
困难 的 ， 那 么 是 否 有 一 个 好 的 框架 可 以 帮助 我 们 轻松 构建 这 么 一 个 应 用 
We? 答案 是 肯定 的 ， 那 就 是 Akka。Akka 是 一 款 遵循 Aapche 2 许可 的 开源 
人 员 ， 这 意味 着 你 可 以 无 偿 并 且 几 乎 没有 限制 地 使 用 它 ， 包 括 将 它 应 用 
于 商业 环境 中 。 


Akka 是 用 Scala 创 建 的 ， 但 由 于 Scala 和 Java 一 样 ， 都 是 Java 虚 拟 机 上 
的 语言 ， 本 质 上 说 ， 两 者 并 没有 什么 不 同 ， 因 此 ， 我 们 也 可 以 在 Java 中 
使 用 Akka。 考 虑 到 Java 开 发 人 员 的 数量 远 远 高 于 Scala， 为 了 方便 大 众 ， 
在 这 里 ， 我 将 全 程 使 用 Java 来 作为 Akka 的 宿主 语言 (本 书 使 用 Akka 
2.11-2.3.7 作 为 演示 ) 。 但 我 并 不 打算 在 这 里 把 对 Akka 的 介绍 写成 一 个 
Akka 使 用 手册 ， 因 此 ， 不 会 对 Akka 进 行 全 方位 完整 的 API 介 绍 。 只 是 希 
望 在 这 里 对 Akka 的 主要 功能 进行 简单 的 摘 述 ， 帮 助 大 家 尽快 理解 Akka 
的 基本 思想 。 








那么 使 用 Akka 能 够 给 我 们 带 来 什么 好 处 呢 ? 


首先 Akka 提 供 了 一 种 称 为 Actor 的 并 发 模型 ， 其 粒度 比 线程 更 小 ， 
这 意味 看 你 可 以 在 系统 中 启用 极其 大 量 的 Actor。 


其 次 ，Akka 中 提供 了 一 套 容错 机 制 ， 人 允许 在 Actor 出 现 异常 时 进行 
一 些 恢复 或 者 重 置 操作 。 





最 后 ， 通 过 Akka 不 仅 可 以 在 单机 上 构建 高 并 发 程序 ， 也 可 以 在 网 络 
中 构建 分 布 式 程序 ， 并 提供 位 置 透明 的 Actor 定 位 服务 。 





下 面 束 让 我 们 正式 开启 Akka 之 旅 吧 ! 


7.1 IFRA: Actor 


对 于 并 发 程序 来 说 ， 线 程 始 终 作为 并 发 程序 的 基本 执行 单元 。 但 在 
Akka 中 ， 你 可 以 完全 忘记 线程 了 。 当 你 使 用 Akka 时 ， 你 束 有 一 个 全 新 
的 执行 单元 Actor。Actor 是 什么 呢 ? 














简单 来 说 ， 你 可 以 把 Actor 比 喻 成 一 个 人 。 多 个 人 之 间 可 以 使 用 语 
言 进行 交流 。 比 如 ， 老 师 问 同学 5 溢 以 5 是 多 少 呀 ? 同学 听 到 问题 后 ， 想 
了 想 ， 回 答 说 是 25。Actor 之 间 的 通信 方式 和 上 述 对 话 形式 几乎 是 一 模 
一 样 的 。 











传统 Java 并 行程 序 ， 还 是 完全 基于 面向 对 象 的 方法 。 我 们 还 是 通过 
对 象 的 方法 调用 进行 信息 的 传递 。 这 时 ， 如 果 对 象 的 方法 会 修改 对 象 本 
吴 的 状态 ， 那 么 在 多 线程 情况 下 ， 束 有 可 能 出 现 对 象 状 态 的 不 一 致 ， 所 
以 我 们 必须 对 这 类 方法 调用 进行 同步 。 当 然 ， 同 步 往往 就 是 以 牺牲 性 能 
为 代价 的 。 





在 Actor 模 型 中 ， 我 们 失去 了 对 象 的 方法 调用 ， 我 们 并 不 是 通过 调 
用 Actor 对 象 的 某 一 个 方法 来 告诉 Actor 你 需要 做 什么 ， 而 是 给 Actor 发 送 
一 条 消 轧 。 当 一 个 Actor 收 到 消息 后 ， 它 有 可 能 会 根据 消 恩 的 内 容 做 出 
某 些 行为 ， 包 括 更 改 自身 状态 。 但 是 ， 在 这 种 情况 下 ， 这 个 状态 的 更 改 
是 Actor 目 己 进行 的 ， 并 不 是 由 外 界 被 迫 进 行 的 。 


7.2 Akka 之 Hello World 


在 了 解 了 Actor 的 基本 行为 模式 后 ， 我 们 通过 简单 的 Hello 


序 来 进一步 了 解 一 下 Akka 的 开发 。 


首先 让 我 们 看 一 下 ， 第 1 个 Actor 的 实现 : 


01 public class Greeter extends UntypedActor { 


02 
03 
04 
05 
06 
07 
08 
09 
10 
11 


public static enum Msg { 


GREET, DONE; 


@Override 
public void onReceive(Object msg) { 
if (msg == Msg.GREET) { 
System.out.printin("Hello World!"); 
getSender().tell(Msg.DONE, getSelf()); 
} else 


unhandled(msg); 


World 程 


上 述 代 码 中 ， 定 义 了 一 个 欢迎 者 (Greeter) Actor， 它 继承 自 


UntypedActor〔 它 自然 就 是 Akka 中 的 核心 成 员 了 ) 。UntypedActor 就 是 
我 们 所 说 的 Actor， 之 所 以 这 里 强调 是 无 类 型 的 ， 那 是 因为 在 Akka 中 ， 
还 文 持 一 种 有 类 型 的 Actor。 有 类 型 的 Actor 可 以 使 用 系统 中 的 其 他 类 型 





构造 ， 可 以 缓解 Java 单 继承 的 问题 。 因 为 你 在 2 e 
就 不 能 再 继承 系统 中 的 其 他 类 了 。 如 果 你 一 定 想 这 么 做 ， 那 么 就 只 能 选 
择 有 类 型 的 Actor。 否 则 ， a His 





在 这 里 ， 人 代码 第 2 一 4 行 ， 定 义 了 消息 类 型 。 这 里 只 有 两 种 类 型 ， 欢 
iW (GREET) 以 及 完成 (DONE) 。 当 Greeter 收 到 GREET 消 息 时 ， 就 
会 在 控制 台 打 印 “Hello World”， 并 且 向 消息 发 送 方 发 送 DONE 信 息 (第 
10 行 ) 。 





与 Greeter 交 流 的 另外 一 个 Actor 是 HellowWorld， 它 的 实现 如 下 : 


01 public class HelloWorld extends UntypedActor { 


02 ActorRef greeter; 

03 

04 @Override 

05 public void preStart() { 

06 greeter = getContext().actorOf(Props.create(Greeter.cl 
07 System.out.println("Greeter Actor Path:" + greeter.pat 
08 greeter.tell(Greeter.Msg.GREET, getSelf()); 

09 } 

10 

11 @Override 

12 public void onReceive(Object msg) { 

13 if (msg == Greeter.Msg.DONE) { 

14 greeter.tell(Greeter.Msg.GREET, getSelf()); 

15 getContext().stop(getSelf()); 

16 } else 


17 unhandled(msg); 


18 1 
19 } 


上 述 代 码 实现 了 一 个 名 为 HelloWorld 的 Actor。 第 5 行 的 preStart0 方 
法 为 Akka 的 回调 方法 ， 在 Actor 启 动 前 ， 会 被 Akka 框 架 调用 ， 完 成 一 些 
初始 化 的 工作 。 在 这 里 ， 我 们 在 HelloWorld 中 创建 了 Greeter 的 实例 (第 
6 行 )， 并 且 疝 它 发 送 GREET 消 息 ( 第 8 行 )。 此 时 ， 由 于 创建 Greeter 
时 使 用 的 是 HelloWorld 的 上 下 文 ， 因 此 ， 它 属于 HelloWorld 的 子 Actor。 


第 12 行 定义 的 onReceive(0) 函 数 为 HelloWorld 的 消息 处 理 函 数 。 在 这 
里 ， 只 处 理 DONE 的 消息 。 在 收 到 DONE 消 息 后 ， 它 会 再 向 Greeter 发 送 
GREET 消 息 ， 接 着 将 自己 停止 。 





此 ，Greeter 会 前 后 收 到 两 条 GREET 消 息 ， 会 打印 两 次 “Hello 
World”. 


最 后 ， 让 我 们 看 一 下 主 函 数 main(): 


1 public class HelloMainSimple { 

2 public static void main(String[] args) { 

3 ActorSystem system = ActorSystem.create("Hello",ConfigFacto 
4 ActorRef a = system.actorOf(Props.create(HellowWorld.cla 
5 System.out.println("Helloworld Actor Path:" + a.path()) 
6 i 

A 


程序 第 3 行 ， 创 建 了 ActorSystem， 表 示 管 理 和 维护 Actor 的 系统 。 一 
般 来 说 ， 一 个 应 用 程序 只 需要 一 个 ActorSystem 就 够 用 了 。 
ActorSystem.create() 的 第 1 个 参数 “Hello” 为 系统 名 称 ， 第 2 个 参数 为 配置 








文件 。 
第 4 行 通 过 ActorSystem 创 建 一 个 顶级 的 Actor (HelloWorld) 。 


配置 文件 samplehello.conf 的 内 容 如 下 : 


akka { 
loglevel = INFO 


在 这 里 ， 只 是 简单 地 配置 了 一 下 日 志 级 别 为 INFO。 
执行 上 述 代 码 ， 可 以 看 到 以 下 输出 : 


1 Helloworld Actor Path:akka://Hello/user/helloworld 

2 Greeter Actor Path:akka://Hello/user/helloworld/greeter 

3 Hello World! 

4 Hello World! 

5 [INFO] [05/13/2015 21:15:01.299] [Hello-akka.actor.default-disp 
[akka://Hello/user/helloWorld] Message [geym.akka.demo.hello.Gree 
Actor [akka: //Hello/user/helloworld/greeter#-1698722495] to 

Actor [akka: //Hello/user/hellowor1ld#-1915075849] was not delivered 
encountered. This logging can be turned off or adjusted with conf 


‘akka.log-dead-letters' and 'akka.log-dead-letters-during-shutdow 


第 1 行 打印 了 HelloWorld Actor 的 路 径 。 它 是 系统 内 第 1 个 被 创建 的 
Actor。 它 的 路 径 为 : akka://Hello/user/helloWorld。 其 中 第 1 个 Hello 表 示 
ActorSystem 的 系统 名 ， 可 以 看 一 下 我 们 构造 这 ActorSystem 时 ， 传 入 的 
第 1 个 参数 就 是 Hello。 接 着 user 表 示 用 户 Actor。 上 所 有 的 用 户 Actor 都 会 挂 





载 在 user 这 个 路 径 下 。 第 3 个 helloWorld 就 是 这 个 Actor 的 名 字 。 


同 理 ， 第 2 个 Greeter Actor 的 路 径 结 构 和 HelloWwWorld 是 完全 一 致 的 。 
输出 的 第 3、4 行 显示 了 Greeter 打 印 的 两 条 信息 。 第 5 行 表 示 系 统 遇 到 了 
条 消息 投递 失败 ， 失 败 的 原因 ei 自己 终止 了 ， 导 致 
Greeter 发 送 的 信息 无 法 投递 。 





可 以 看 到 ， 妆 使 用 Actor 进 行 并 行程 序 开 发 时 ， 我 们 的 关注 点 已 经 
不 在 线程 上 了 。 实 际 上 ， 线 程 调度 已 经 被 Akka 框 架 ale 我 们 只 需 
要 关注 Actor 对 象 即 可 。 而 Actor 对 象 之 间 的 交流 和 普 oe - 象 的 函数 调 
用 有 明显 区 别 。 它 们 是 通过 显示 的 消息 发 送 来 传递 信息 





当 系 统 内 有 多 个 Actor 存 在 时 ，Akka 会 自动 在 线程 池 中 选择 线程 来 
执行 我 们 的 Actor。 因 此 ， 多 个 不 同 的 Actor 有 可 能 会 被 同一 个 线程 执 
行 ， 同 时 ， 一 个 Actor 也 有 可 能 被 不 同 的 线程 执行 。 因 此 ， 一 个 值得 注 
意 的 地 方 是 : 不 要 在 一 个 Actor 中 执行 耗 时 的 代码 ， 这 样 可 能 会 导致 其 
他 Actor 的 调度 出 现 问 题 。 





7.3 有关 消息 投 鸳 的 一 些 说 明 


整个 Akka 应 用 是 由 消息 驱动 的 。 消 息 是 除了 Actor 之 外 最 重要 的 核 
心 组 件 。 作 为 在 并 发 程序 中 的 核心 组 件 ， 在 Actor 之 间 传 递 的 消息 应 该 
满足 不 可 变性 ， 也 吏 是 不 变 模 式 。 因 为 可 变 的 消 妃 无 法 高 效 的 在 并 发 环 
卉 中 使 用 。 理 论 上 Akka 中 的 消息 可 以 使 用 任何 对 象 实例 ， 但 实际 使 用 
中 ， 强 烈 推荐 使 用 不 可 变 的 对 象 。 一 个 典型 的 不 可 变 对 象 的 实现 如 下 : 











01 public final class ImmutableMessage { 


02 private final int sequenceNumber ; 

03 

04 private final List<String> values; 

05 

06 public ImmutableMessage(int sequenceNumber, List<String> 
07 this.sequenceNumber = sequenceNumber; 

08 this.values = Collections.unmodifiableList(new ArrayLi 
09 } 

10 

11 public int getSequenceNumber() { 

12 return sequenceNumber ; 

13 } 

14 

15 public List<String> getValues() { 

16 return values; 


17 } 


18 } 





上 述 代码 实现 了 一 个 不 可 变 的 消息 。 注 意 代 码 中 对 final 的 使 用 ， 它 
申明 了 当前 消息 中 的 几 个 字段 都 是 常量 ， 在 消息 构造 完成 后 ， 就 不 能 
发 生 改 变 了 。 更 加 需要 注意 的 是 ， 对 于 values 字 段 ，final 关 键 字 只 能 保 
证 values 引 用 的 不 可 变性 ， 并 无 法 保证 values 对 象 的 不 可 变性 。 为 了 实现 
彻底 的 不 可 变性 ， 代 码 第 8 行 构 造 了 一 个 不 可 变 的 List 对 象 。 














对 于 消息 投递 ， 大 家 可 能 还 有 另外 一 个 疑问 ， 那 就 是 消息 投递 完 竟 
征 以 何 种 策略 进行 的 呢 ? 也 就 是 发 出 去 的 消息 一 定 会 被 对 方 接收 到 吗 ? 
如 果 接 收 不 到 会 重 发 吗 ? 有 没有 可 能 重复 接收 消息 呢 ? 





实际 上 ， 对 于 消 妃 投递 ， 我 们 可 以 有 3 种 不 同 的 策略 : 





第 1 种 ， 称 为 至 多 一 次 投递 。 在 这 种 策略 中 ， 每 一 条 消息 最 多 会 家 
投递 一 次 。 在 这 种 情况 下 ， 可 能 偶尔 会 出 现 消 妃 投 递 失败 ， 而 导致 消 妃 
ERs 





第 2 种 称 为 至 少 一 次 投递 。 在 这 种 策略 中 ， 每 一 条 消息 至 少 会 被 投 
圳 一 次 ， 直 到 成 功 为 止 。 因 此 在 一 些 偶然 的 场合 ， 接 受 者 可 能 会 收 到 重 
复 的 消 轧 ， 但 不 会 发 生 消 妃 丢失 。 








第 3 种 称 为 精确 的 消息 投递 。 也 就 是 所 有 的 消 妃 保证 被 精确 地 投递 
并 成 功 接收 一 次 ， 既 不 会 有 丢失 ， 也 不 会 有 重复 接收 。 








很 明显 ， 第 1 种 策略 是 最 高 性 能 ， 最 低 成 本 的 。 因 为 系统 只 要 负责 
把 消 妃 送出 去 就 可 以 了 ， 不 需要 关注 是 否 成 功 。 第 2 种 策略 则 需要 保存 
消息 投递 的 状态 并 不 断 充 实 。 而 第 3 种 策略 则 是 成 本 最 高 且 最 不 容易 实 
现 的 。 














那 我 们 是 人 否 真 的 需要 保证 消 恩 投递 的 可 靠 性 呢 ? 


答案 是 否定 的 。 实 际 上 ， 我 们 没有 必要 在 Akka 层 保证 消息 的 可 徘 
性 。 这 样 做 ， 成 本 太 高 了 ， 也 是 没有 必要 的 。 消 妃 的 可 靠 性 更 应 该 在 应 
用 的 业务 层 去 维护 ， 因 为 也 许 在 有 些 时 候 ， 丢 失 一 些 消 息 完 全 是 符合 应 
用 要 求 的 。 因 此 ， 在 使 用 Akka 时 ， 需 要 在 业务 层 对 此 进行 保证 。 





此 外 ， 对 于 消息 投递 Akka 可 以 在 一 定 程度 上 保证 顺序 性 。 比 如 ， 
Actor A1 向 A2 顺 序 发 送 了 M1、M2 和 M3 三 条 消息 。Actor A3 向 A2 顺 序 发 
送 了 M4、M5 和 M6 三 条 消息 。 那 么 系统 可 以 保证 : 








(1) 如 果 M1 没 有 丢失 ， 那 它 一 定 先 于 M2 和 M3 被 A2 收 到 。 
(2) 如 果 M2 没 有 丢失 ， 那 它 一 定 先 于 M3 被 A2 收 到 。 
(3) 如 果 M4 没 有 丢失 ， 那 它 一 定 先 于 M5 和 M6 被 A2 收 到 。 
(4) 如 果 M5 没 有 丢失 ， 那 它 一 定 先 于 M6 被 A2 收 到 。 


(5) 对 A2 来 说 ， 来 和 目 A1 和 A3 的 消息 可 能 交织 在 一 起 ， 没 有 顺序 保 
证 。 








在 这 里 ， 值 得 注意 的 一 点 是 ， 这 种 消息 投递 规则 不 有 具备 可 传递 性 ， 
比如 : 


Actor A 向 C 发 送 了 M1， 接 着 ，Actor A 向 B 发 送 了 M2，B 将 M2 转发 
给 Actor C。 那 么 在 这 种 情况 下 ，C 收 到 M1 和 M2 的 先后 顺序 是 没有 保证 
的 。 





7.4 Actor} Æ m J HH 


Actor 在 系统 中 产生 后 ， 也 存在 着 “生老病死 ?的 活动 周期 。Akka 框 
架 提 供 了 知 干 回调 函数 ， 让 我 们 得 以 在 Actor 的 活动 周期 内 进行 一 些 业 
务 相 关 的 行为 。Actor 的 生命 周期 如 图 7.1 所 示 。 


HEA eof PStRestert ; 


re FES ARG] 
| Resume fo) @) 


Yestot- 





STOP , Pasion Uf 


图 7.1 Actor 的 生命 周期 


一 个 Actor 在 actorOfO 函 数 被 调用 后 开始 建立 ，Actor 实 例 创 建 后 ， 
会 回调 preStart() 方 法 。 在 这 个 方法 里 ， 我 们 可 以 进行 一 些 资源 的 初始 化 
工作 。 在 Actor 的 工作 过 程 中 ， 可 能 会 出 现 一 些 异常 ， 这 种 情况 下 ， 
Actor 会 需要 重启 。 当 Actor 被 重启 时 ， 会 回调 preRestart() 方 法 (在 老 的 
实例 上 ) ， 接 着 系统 会 创建 一 个 新 的 Actor 对 象 实例 ( 虽 然 是 新 的 实 
例 ， 但 它们 都 表示 同一 个 Actor) 。 当 新 的 Actor 实 例 创 建 后 ， 会 回调 
postRestart() 方 法 ， 表 示 启 动 完成 ， 同 时 新 的 实例 将 会 代 蔡 旧 的 实例 。 停 
正 一 个 Actor 也 有 很 多 方式 ， 你 可 以 调用 stop() 方 法 或 者 给 Actor 发 送 一 个 




















PosionPill 〈 毒 药丸 ) 。Actor 停 止 时 ，postStop(0) 方 法 会 被 调用 ， 同 时 这 
个 Actor 的 监视 者 会 收 到 一 个 Terminated 消 息 。 





下 和 面 让 我 们 建立 一 个 带 有 生命 周期 回调 函数 的 Actor: 


public class MyWorker extends UntypedActor { 
private final LoggingAdapter log = Logging.getLogger(getConte 
public static enum Msg { 
WORKING, DONE, CLOSE; 
} 
@Override 
public void preStart(){ 
System.out.println("MyWorker is starting"); 
} 
@Override 
public void postStop(){ 
System.out.println("MyWorker is stopping"); 
} 
@Override 
public void onReceive(Object msg) { 
if (msg == Msg.WORKING) { 
System.out.println("I am working"); 
} 
if (msg == Msg.DONE) { 
System.out.println( "Stop working"); 
}if (msg == Msg.CLOSE) { 


System.out.printin("I will shutdown"); 


getSender().tell(Msg.CLOSE, getSelf()); 
getContext().stop(getSelf()); 
} else 


unhandled(msg); 


上 述 代 码 定 义 了 一 个 名 为 MyWorker 的 Actor。 它 重 载 了 preStart0 和 
postStop() 两 个 方法 。 Bice. 我 们 可 以 合用 preStart0 来 初始 化 一 些 资 
源 ， 使 用 postStop0) 来 进行 资源 的 释放 。 这 个 Actor 很 简单 ， 当 它 收 到 
WORKING 消 息 时 ， 就 打印 和 ”am ”working”， 收 到 DONE 消 息 时 ， 打 
印 “Stop working”。 


接着 ,我们 为 MyWorker 指 定 一 个 监视 者 ， 监 视 者 就 如 同一 个 劳动 
监工 ,一旦 MyWorker 因 为 意外 停止 工作 ， 监 视 者 就 会 收 到 一 个 通知 。 





01 public class WatchActor extends UntypedActor { 


02 private final LoggingAdapter log = Logging.getLogger(getCo 
03 

04 public WatchActor(ActorRef ref) { 

05 getContext().watch(ref); 

06 } 

07 

08 @Override 

09 public void onReceive(Object msg) { 

10 if (msg instanceof Terminated) { 

11 System.out.printin(String.format("%s has terminate 


12 ((Terminated) msg).getActor().path())); 


13 getContext().system().shutdown(); 


14 } else { 

15 unhandled(msg); 
16 } 

17 } 

18 } 


上 述 代码 定义 了 一 个 监视 者 WatchActor， 它 本 质 上 也 是 一 个 Actor， 
但 不 同 的 是 ， 它 会 在 它 的 上 下 文中 watch 一 个 Actor〈 第 5 行 ) 。 如 果 将 来 
这 个 被 监视 的 Actor 的 退出 终止 ，WatchActor 就 能 收 到 一 条 Terminated 消 
轧 《 人 代码 第 10 行 ) 。 在 这 里 ， 我 们 将 简单 地 打印 终止 消息 Terminated 中 
的 相关 Actor 路 径 ， 并 且 关 闭 整个 ActorSystem 《第 13 行 ) 。 





主 函数 如 下 : 
01 public class DeadMain { 
02 public static void main(String[] args) { 
03 ActorSystem system = ActorSystem 
04 .create("deadwatch", ConfigFactory.load("sampl 
05 ActorRef worker = system.actorOf(Props.create(MyWorker 
06 system.actorOf(Props.create(WatchActor.class, worker), 
07 worker.tell(MyWorker.Msg.WORKING, ActorRef.noSender()) 
08 worker.tell(MyWorker.Msg.DONE, ActorRef.noSender()); 
09 worker.tell(PoisonPill.getInstance(), ActorRef.noSende 
10 } 
11 } 


上 述 代 码 中 ， 我 们 首先 创建 ActorSystem 全 局 实例 〈 第 3 一 4 行 ) ， 


接着 创建 MyWorker ”Actor 和 WatchActor。 注 意 第 6 行 的 Props.create() 方 
法 ， 它 的 第 1 个 参数 为 要 创建 的 Actor 类 型 ， 第 2 个 参数 为 这 个 Actor 的 构 
造 函 数 的 参数 (在 这 里 ， 就 是 要 调用 WatchActor 的 构造 函数 ) 。 接 着 ， 
向 MyWorker 先 后 发 送 WORKING 和 DONE 两 条 消息 。 最 后 在 第 9 行 ， 发 
送 一 条 特殊 的 消息 PoisonPill。PoisonP 记 就 是 毒药 丸 ， 它 会 直接 毒 死 接 
收 方 ， 让 其 终止 。 























执行 上 述 代 码 ， 系 统 输 出 如 下 : 


MyWorker is starting 
I am working 
Stop working 
MyWorker is stopping 


akka://deadwatch/user/worker has terminated, shutting down system 


从 这 个 输出 中 可 以 看 到 ，MyWorker 生 命 周期 中 的 两 个 回调 函数 以 
及 消息 处 理 函 数 都 被 正常 调用 。 最 后 一 行 输出 也 显示 WatchActor 正 常 监 
视 到 MyWorker 的 终止 。 


7.5 监督 策略 


如 果 一 个 Actor 在 执行 过 程 中 发 生意 外 ， 比 如 没有 处 理 某 些 异 常 ， 
导致 出 错 ， 那 么 这 个 时 候 应 该 怎么 办 呢 ? 系 统 是 应 该 当做 什么 都 没 发 生 
过 ， 继 续 执 行 ， 还 是 认为 过 到 了 一 个 系统 性 的 错误 而 重启 Actor 其 至 是 
它 所 有 的 兄弟 Actor 呢 ? 





对 于 这 种 情况 ，Akka 框 架 给 予 了 我 们 足够 的 控制 权 。 在 Akka 框 架 
内 ， 父 Actor 可 以 对 子 Actor 进 行 监督 ， 监 控 Actor 的 行为 是 否 有 异常 。 大 
体 上 ， 监 督 策略 可 以 分 为 两 种 : 一 种 是 OneForOneStrategy 的 监督 ， 男 外 
一 种 是 AllForOneStrategy。 








对 于 OneForOneStrategy 的 策略 ， 父 Actor 只 会 对 出 问题 的 子 Actor 进 
行 处 理 ， 比 如 重启 或 者 停止 ， 而 对 于 AllForOneStrategy， 父 Actor 会 对 出 
问题 的 子 Actor 以 及 它 所 有 的 兄弟 都 进行 处 理 。 很 显然 ， 对 于 
AllForOneStrategy 策 略 ， 它 更 加 适合 于 各 个 Actor 联 系 非 常 紧密 的 场景 ， 
如 果 多 个 Actor 间 只 要 有 一 个 Actor 出 现 故 障 ， 则 宣告 整个 任务 失败 ， 就 
比较 适合 使 用 AllForOneStrategy， 人 否则 ， 在 更 多 的 场景 中 ， 应 该 使 用 
OneForOneStrategy。 当 然 了 ，OneForOneStrategy 也 是 Akka 的 默认 策 
ig o 


在 一 个 指定 的 策略 中 ， 我 们 可 以 对 Actor 的 失败 情况 进行 相应 的 处 
理 ， 比 如 : 当 失 败 时 ， 我 们 可 以 无 视 这 个 错误 ， 继 续 执 行 Actor， 束 像 
什么 事 都 没 发 生 过 一 样 。 或 者 可 以 重启 这 个 Actor， 甚 至 可 以 让 这 个 
Actor 彻 确 停 止 工作 。 要 指定 这 些 监督 行为 ， 只 要 构造 一 个 目 定义 的 监 
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下 面 让 我 们 简单 看 一 下 SupervisorStrategy 的 使 用 和 设置 。 首 先 ， 需 
要 定 一 个 父 Actor， 它 作为 所 有 子 Actor 的 监督 者 : 


01 public class Supervisor extends UntypedActor { 


02 private static SupervisorStrategy strategy = new OneForOneStra 


03 new Function<Throwable, Directive>() { 

04 @Override 

05 public Directive apply(Throwable t) { 

06 if (t instanceof ArithmeticException) { 

07 System.out.println("meet ArithmeticExc 
08 return SupervisorStrategy.resume(); 

09 } else if (t instanceof NullPointerExcepti 
10 System.out.println("meet NullPointerEx 
al return SupervisorStrategy.restart(); 
12 } else if (t instanceof IllegalArgumentExc 
13 return SupervisorStrategy.stop(); 

14 y &lse { 

15 return SupervisorStrategy.escalate(); 
16 } 

17 } 

18 }); 

19 

20 @Override 

21 public SupervisorStrategy supervisorStrategy() { 

22 return strategy; 

23 } 


25 public void onReceive(Object o) { 


26 if (o instanceof Props) { 

27 getContext().actorOf((Props) o,"restartActor"),; 
28 } else { 

29 unhandled(o); 

30 } 

31 } 

32 } 


上 述 代码 第 2 一 18 行 ， 定 义 了 一 个 OneForOneStrategy 的 监督 策略 。 
在 这 个 监督 策略 中 ， 运 行 Actor 在 遇 到 错误 后 ， 在 1 分 钟 内 进行 3 次 重 
试 。 如 果 超 过 这 个 频率 ， 那 么 就 会 直接 杀 死 Actor。 具 体 的 策略 由 第 5~ 
16 行 定义 。 这 里 的 含义 是 ， 当 过 到 ArithmeticException 异 和 常 时 (比如 除 
以 0 的 错误 ) ， 继 续 指定 这 个 Actor， 不 做 任何 处 理 〈 第 8 行 ) ; 当 遇 到 
空 指针 时 ， 进 行 Actor 的 重启 《第 11 行 ) 。 如 果 遇 到 
IllegalArgumentException #3, WERE IE Actor (21347) 。 对 于 在 这 
ARAPA WKE NUE, EU A Actorkh EH (3815 
ITY 





第 20 一 23 行 履 盖 父 类 的 supervisorStrategy0) 方 法 ， 设 置 使 用 自 定 义 的 
监督 策略 。 


第 27 行 用 来 新 建 一 个 名 为 restartActor 的 子 Actor， 这 个 子 Actor 就 由 
当前 的 Supervisor 进 行 监督 了 。 当 Supervisor 接 收 一 个 Props 对 象 时 ， 就 会 
根据 这 个 Props 配 置 生 成 一 个 restartActor。 


RestartActor 的 实现 如 下 : 


01 public class RestartActor extends UntypedActor { 


02 
03 
04 
05 
06 
07 
08 
09 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 


public enum Msg { 
DONE, RESTART 


@Override 
public void preStart() { 


System.out.printin("preStart hashcode:" + this.hashCod 


@Override 
public void postStop() { 


System.out.println("postStop hashcode:" + this.hashCod 


@Override 
public void postRestart(Throwable reason) throws Exception 
super .postRestart(reason); 


System.out.println("postRestart hashcode:" + this.hash 


@Override 
public void preRestart(Throwable reason,Option opt) throws 


System.out.println("preRestart hashcode:" + this.hashc 


@Override 


28 public void onReceive(Object msg) { 








29 if (msg == Msg.DONE) { 

30 getContext().stop(getSelf()); 

31 } else if (msg == Msg.RESTART) { 

32 System.out.println(((Object)null).toString()); 
33 // 抛 出 异常 默认 会 被 restart， 但 这 里 会 resume 

34 double a = 0 / 0; 

35 } 

36 unhandled(msg); 

37 } 

38 } 


第 6 一 25 行 ， 定 义 了 一 些 Actor 的 生命 周期 的 回调 接口 。 目 的 是 更 好 
地 观察 Actor 的 活动 情况 。 在 第 32 一 34 行 模拟 了 一 些 异 常情 况 ， 第 32 行 
会 抛 出 NullPointerException， 而 第 34 行 因为 除 以 零 ， 所 以 会 抛 出 
ArithmeticException. 


主 函 数 如 下 定义 : 


01 public static void customStrategy(ActorSystem system) { 


02 ActorRef a = system.actorOf(Props.create(Supervisor.class) 
03 a.tell(Props.create(RestartActor.class), ActorRef.noSender 
04 

05 ActorSelection 


sel=system.actorSelection("akka://lifecycle/user/Supervisor/resta 
06 
07 for(int i=0;i<100;i++){ 


08 sel.tell(RestartActor.Msg.RESTART, ActorRef.noSender() 


09 } 

10 } 

11 public static void main(String[] args) { 

12 ActorSystem system = ActorSystem.create("lifecycle", 
ConfigFactory.load("lifecycle.conf")); 

13 customStrategy(system); 

14 } 


上 述 代 码 中 ， 第 12 行 代码 创建 了 全 局 ActorSystem， 接 着 在 
customStrategy() 函 数 中 创建 了 Supervisor Actor， 并 且 对 Supervisor 发 送 一 
个 RestartActor 的 Props《〈 第 3 行 ， 这 个 消息 会 使 得 Supervisor 创 建 
RestartActor) 。 


接着 ， 选 中 RestartActor 实 例 〈 第 5 行 ) 。 第 7 一 9 行 ， 同 这 个 
RestartActor 发 送 100 条 RESTART 消 息 。 这 会 使 得 RestartActor 抛 出 


NullPointerException. 


执行 上 述 代 码 ， 部 分 输出 如 下 由 于 输出 太 多 ， 这 里 只 截取 重要 的 


部 分 ) : 


Ok 


01 preStart hashcode: 7302437 

02 meet NullPointerException, restart 

03 preRestart hashcode: 7302437 

04 [ERROR] [lifecycle-akka.actor.default-dispatcher-3] [akka://1i 
restartActor] null 

05 java.lang.NullPointerException 

06 at geym.akka.demo.lifecycle.RestartActor.onReceive(Restart. 


07 at akka.actor.UntypedActor$$anonfun$receive$1.applyOrElse( 


08 
09 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
24 
22 
23 
24 
25 
26 
27 
28 
29 
30 


at akka.actor.Actor$class.aroundReceive(Actor.scala:465) 
at akka.actor.UntypedActor.aroundReceive(UntypedActor.scal 
at akka.actor.ActorCell.receiveMessage(ActorCell.scala:516 
at akka.actor.ActorCell.invoke(ActorCell.scala: 487) 


at akka.dispatch.Mailbox.processMailbox(Mailbox.scala:254) 


at akka.dispatch.Mailbox.run(Mailbox.scala:221) 


at akka.dispatch.Mailbox.exec(Mailbox.scala:231) 


at scala.concurrent.forkjoin.ForkJoinTask.doExec(ForkJoinT 
at scala.concurrent.forkjoin.ForkJoinPool$workQueue.runTas 
at scala.concurrent.forkjoin.ForkJoinPool.runworker(ForkJo 


at scala.concurrent.forkjoin.ForkJoinWorkerThread.run(Fork 


preStart hashcode: 23269863 
postRestart hashcode: 23269863 
meet NullPointerException, restart 
preRestart hashcode: 23269863 
preStart hashcode: 24918371 
postRestart hashcode: 24918371 
meet NullPointerException, restart 
preRestart hashcode: 24918371 
preStart hashcode:12844205 
postRestart hashcode:12844205 


[ERROR] [lifecycle-akka.actor.default-dispatcher -2] 


[akka://lifecycle/user/Supervisor/restartActor] n ull 


31 


33 


meet NullPointerException, restart 


postStop hashcode:12844205 


第 1 行 的 preStart 表 示 RestartActor 正 在 初始 化 ， 注 意 它 的 HashCode 为 
7302437。 接 着 ， 这 个 Actor 遇 到 了 NullPointerException。 根 据 自 定 义 的 
策略 ， 这 将 导致 它 重 局 ， 因 此 ， 这 就 有 了 第 3 行 的 preRestart， 因 为 
preRestart 在 正式 重启 之 前 调用 ， 因 此 HashCode 还 是 7302437， 表 示 当 前 
Actor 和 上 一 个 Actor 还 是 同一 个 实例 。 接 着 ， 第 4 一 19 行 打印 了 腊 和 单 信 
自 
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第 20 行 进入 了 preStart() 方 法 ， 它 的 HashCode 为 23269863。 这 说 明 系 
统 已 经 为 这 个 RestartActor 生 成 了 一 个 新 的 实例 ， 原 有 的 实例 因为 重启 而 
被 回收 。 新 的 实例 将 代替 原 有 实例 继续 工作 。 这 说 明 同 一 个 RestartActor 
在 系统 的 工作 始终 ， 未 必 能 保持 同一 个 实例 。 重 司 完成 后 ， 调 用 
postRestart() 方 法 (第 21 行 )。 实 际 上 ，Actor 重 启 后 的 preStart() 方 法 ， 
就 是 在 postRestart() 中 调用 的 《Actor 父 类 的 postRestart() 会 调用 preStart() 
IIN 





在 经 过 3 次 重启 后 ， 超 过 了 监督 策略 中 的 单位 时 间 内 的 重 试 上 限 。 
因此 ， 系 统 不 会 再 进行 尝试 ， 而 是 直接 关闭 RestartActor。 上 述 输出 中 第 
33 行 就 显示 了 这 个 过 程 ， 在 最 后 一 个 RestartActor 实 例 上 ， 执 行 了 停止 方 
TE 0 


7.6 ”选择 Actor 





在 一 个 ActorSystem 中 ， 可 能 存在 大 量 的 Actor。 如 何 才能 有 效 地 对 
大 量 Actor 进 行 批量 的 管理 和 通信 呢 ? Akka 为 我 们 提供 了 一 个 
ActorSelection 类 ， 用 来 批量 进行 消息 发 送 。 限 于 篇 幅 有 限 ， 这 里 不 再 给 
出 完整 的 代码 ， 示 意 代码 如 下 : 











1 for(int i=0;i<WORDER COUNT;i++){ 

2 workers.add(system.actorOf(Props.create(MyWorker.class,1), 
3 } 

4 

5 ActorSelection selection = getContext().actorSelection("/user/w 


6 selection.tell(5, getSelf()); 


上 述 代码 第 1 一 3 行 ， 批 量 生成 了 大 量 Actor。 接 着 ， 我 们 要 给 这 些 
worker 发 送 消息 ， 通 过 actorSelection() 方 法 提供 的 选择 通配符 〈 第 5 
ÍT) ， 可 以 得 到 代表 所 有 满足 条 件 的 ActorSelection。 第 6 行 ， 通 过 这 个 
ActorSelection 实 例 ， 便 可 以 向 所 有 woker Actor 发 送 消息 。 





7.7 HEIFI (Inbox) 





我 们 已 经 知道 ， 所 有 Actor 之 间 的 通信 都 是 通过 消 恩 来 进行 的 。 这 


?意味 着 我 们 必须 构建 一 个 Actor 来 控制 整个 系统 呢 ? 答案 是 否定 


日 
ER 


的 ， 


我 们 并 不 一 定 要 这 么 做 ，Akka 框 架 已 经 为 我 们 准备 了 一 个 叫做 “ 收 


件 箱 ” 的 组 件 ， 使 用 收 件 箱 ， 可 以 很 方便 地 对 Actor 进 行 消 息 发 送 和 接 


收 ， 


大 大 方便 了 应 用 程序 与 Actor 之 间 的 交互 。 


下 面 定义 了 当前 示例 中 唯一 一 个 Actor: 


01 public class MyWorker extends UntypedActor { 


02 
03 
04 
05 
06 
07 
08 
09 
10 
di 
12 
13 
14 
15 
16 


private final LoggingAdapter log = Logging.getLogger(getCo 
public static enum Msg { 


WORKING, DONE, CLOSE; 


@Override 
public void onReceive(Object msg) { 
if (msg == Msg.WORKING) { 
log.info("I am working"); 
} 
if (msg == Msg.DONE) { 
log.info("Stop working"); 
}if (msg == Msg.CLOSE) { 
log.info("I will shutdown") ; 
getSender().tell(Msg.CLOSE, getSelf()); 


17 getContext().stop(getSelf()); 


18 } else 

19 unhandled(msg); 
20 } 

21 } 


上 述 代码 中 ，MyWorker 会 根据 收 到 的 消息 打印 自己 的 工作 状态 。 
当 接 收 到 CLOSE 消 息 时 (第 14 行 )， 会 关闭 自己 ， 结 束 运 行 。 





而 在 本 例 中 ， 与 这 个 MyWorker ” Actor 交互 的 ， 并 不 是 一 个 Actor,， 
而 是 一 个 邮箱 ， 邮 箱 的 使 用 很 简单 : 


01 public static void main(String[] args) { 

02 ActorSystem system = ActorSystem.create("inboxdemo", ConfigFac 
03 ActorRef worker = system.actorOf(Props.create(MyWorker.class 
04 

05 final Inbox inbox = Inbox.create(system); 

06 inbox.watch(worker); 

07 inbox.send(worker, MyWorker .Msg.WORKING); 

08 inbox.send(worker, MyWorker .Msg.DONE); 

09 inbox.send(worker, Myworker .Msg.CLOSE); 

10 


11  while(true){ 


12 Object msg = inbox.receive(Duration.create(1, TimeUnit.S 
13 if (msg==MyWorker .Msg.CLOSE) { 

14 System.out.printin("My worker is Closing"); 

15 yelse if(msg instanceof Terminated) { 


16 System.out.println("My worker is dead"); 


17 system.shutdown(); 


18 break; 

19 selse{ 

20 System.out.println(msg) ; 
21 } 

22 } 

23 } 


上 述 代码 中 ， 第 5 行 ， 根 据 ActorSystem 构 造 了 一 个 与 之 绑 定 的 邮箱 
Inbox。 接 着 使 用 邮箱 监视 MyWorker (第 6 行 ) ， 这 样 就 能 在 MyWorker 
停止 后 得 到 一 个 消息 通知 。 第 7 一 9 行 ， 通 过 邮箱 向 MyWorker 发 送 消 
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在 第 11 一 21 行 ， 进 行 消息 接收 ， 如 果 发 现 MyWorker 已 经 停止 工 
作 ， 则 关闭 整个 ActorSystem 〈 第 17 行 ) 。 


执行 上 述 代 码 ， 输 出 如 下 《为 节省 版 面 ， 我 对 输出 进行 了 一 些 简 单 
的 删 减 ) : 


[INFO] [inboxdemo-akka.actor.default-dispatcher-3] [akka://inboxd 
working 

[INFO] [inboxdemo-akka.actor.default-dispatcher-3] [akka://inboxd 
working 

[INFO] [inboxdemo-akka.actor.default-dispatcher-3] [akka://inboxd 
shutdown 

My worker is Closing 


My worker is dead 


上 述 输出 的 前 3 行为 MyWorker 的 输出 日 志 ， 表 示 MyWorker Actor 的 
工作 状态 。 后 两 行为 主 函 数 main() 中 对 MyWorker 消 息 的 处 理 。 


7.8 消息 路 由 


Akka 提 供 了 非常 灵活 的 消息 发 送 机 制 。 有 时 候 ， 我 们 也 许 会 使 用 一 
组 Actor 而 不 是 一 个 Actor 来 提供 一 项 服务 。 这 一 组 Actor 中 所 有 的 Actor 都 
是 对 等 的 ， 也 就 是 说 你 可 以 找 任何 一 个 Actor 来 为 你 服务 。 这 种 情况 
下 ， 如 何 才能 快速 有 效 地 找到 合适 的 Actor 呢 ? 或 者 说 如 何 调度 这 些 消 
轧 ， 才 可 以 使 负载 更 为 均衡 地 分 配 在 这 一 组 Actor 中 。 


为 了 解决 这 个 问题 ，Akka 使 用 一 个 路 由 器 组 件 (Router) 来 封装 消 
恩 的 调度 。 系 统 提供 了 几 种 实用 的 消 恩 路 由 策略 ， 比 如 ， 轮 询 选择 
Actor 进 行 消息 发 送 ， 随 机 消息 发 送 ， 将 消息 发 送 给 最 为 空闲 的 Actor， 
甚至 是 在 组 内 广播 消息 。 





下 面 就 来 演示 一 下 消息 路 由 的 使 用 方式 : 


01 public class WatchActor extends UntypedActor { 


02 private final LoggingAdapter log = Logging.getLogger(getCo 
03 public Router router; 

04 { 

05 List<Routee> routees=new ArrayList<Routee>(); 

06 for(int 1=0;1<5;i++){ 

07 ActorRef worker = getContext().actorOf(Props.create 
08 getContext().watch(worker ); 

09 routees.add(new ActorRefRoutee(worker) ); 

10 } 


11 router=new Router(new RoundRobinRoutingLogic(),routees 


12 } 


13 

14 @Override 

15 public void onReceive(Object msg) { 

16 if(msg instanceof MyWorker.Msg) { 

17 router.route(msg, getSender()); 

18 yelse if (msg instanceof Terminated) { 

19 router=router.removeRoutee(((Terminated)msg).actor()); 
20 System.out.printin(((Terminated)msg).actor().path()+" 


routees().size()); 


21 if(router.routees().size()==0){ 

22 System.out.printin("Close system"); 
23 RouteMain.flag.send(false); 

24 getContext().system().shutdown(); 
25 } 

26 } else { 

27 unhandled(msg); 

28 } 

29 } 

30 } 


上 述 代 人 码 中 定义 了 WatchActor。 第 3 行 ， 就 是 路 由 器 组 件 Router， 在 
构造 Router 时 ， 需 要 指定 路 由 策略 和 一 组 被 路 由 的 Actor (Routee) ， 如 
第 11 行 所 示 。 这 里 使 用 了 RoundRobinRoutingLogic 路 由 策略 ， 也 就 是 对 
所 有 的 Routee 进 行 轮 询 消 息 发 送 。 在 本 例 中 ，Routee 由 5 个 MyWorker 
Actor 构 成 〈 第 6 一 10 行 ，MyWorker 与 上 一 节 中 的 相同 ， 故 不 再 给 出 代 
AZ) « 


当 有 消息 需要 传递 给 这 5 个 MyWorker 时 ， 只 需要 将 消息 投递 给 这 个 
Router 即 可 〈 上 述 代码 第 17 行 ) 。Ronuter 就 会 根据 给 定 的 消息 路 由 策略 
进行 消息 投递 。 当 一 个 MyWorker 停 止 工 作 时 ， 还 可 以 简单 地 将 其 从 工 
作 组 中 移 除 (第 19 行 )。 在 这 里 ， 如 果 发 现 系统 中 没有 可 用 的 Actor， 
就 会 直接 关闭 系统 。 


主 函 数 比较 简单 ， 如 下 : 


01 public class RouteMain { 
02 public static Agent<Boolean> flag=Agent.create(true, Execut 


03 public static void main(String[] args) throws InterruptedExc 


04 ActorSystem system = ActorSystem.create("route", ConfigFac 
05 ActorRef w=system.actorOf(Props.create(WatchActor.class), 
06 int =í 

07 while(flag.get()){ 

08 w.tell(MyWorker.Msg.WORKING, ActorRef.noSender()); 

09 if (i%10==0)w.tell(MyWworker.Msg.CLOSE, ActorRef.noSende 
10 aes 

11 Thread.sleep(100); 

12 } 

13h 

14 } 








上 述 代 码 癌 WatchActor 发 送 大 量 消息 ， 其 中 夹杂 着 几 条 关闭 Actor 的 
消息 。 这 会 使 得 MyWorker Actor 逐 一 被 关闭 ， 最 终 程 序 将 退出 。 


这 段 程序 的 部 分 输出 如 下 《做 过 适量 裁 甬 ) : 


[INFO][route-akka.actor.default-dispatcher-3] 
working 
[INFO][route-akka.actor.default-dispatcher-3] 
working 
[INFO][route-akka.actor.default-dispatcher-3] 
working 
[INFO][route-akka.actor.default-dispatcher-4] 
working 
[INFO][route-akka.actor.default-dispatcher-3] 
working 
[INFO][route-akka.actor.default-dispatcher-3] 


working 


[akka: 


[akka: 


[akka: 


[akka: 


[akka: 


[akka: 


//route/user/ 


//route/user/ 


//route/user/ 


//route/user/ 


//route/user/ 


//route/user/ 


[INFO] [route-akka.actor.default-dispatcher-2] [akka://route/user/ 


shutdown 


akka://route/user/watcher/worker_1 is closed, routees=0 


Close system 


可 以 看 到 ，WORKING 消 息 被 轮流 发 送 给 这 5 个 worker。 大 家 可 以 修 


改 路 由 人 策略， 观察 不 同 路 由 沉 略 下 的 消息 投递 方式 《除了 


RoundRobinRoutingLogic 外 ， 还 可 以 尝试 BroadcastRoutingLogic 广 播 策 
略 、RandomRoutingLogic 随 机 投递 策略 、SmallestMailboxRoutingLogic 


空 亲 Actor 优 先 投递 策略 ) 。 


7.9 Actor 的 内 症状 态 较 换 


在 很 多 场景 下 ，Actor 的 业务 逻辑 可 能 比较 复 杀 ，Actor 可 能 需要 根 
所 不 同 的 状态 对 同一 条 消息 作出 不 同 的 处 理 。Akka 已 经 为 我 们 考 碟 到 了 
这 一 点 ， 一 个 Actor 内 部 消 恩 处 理 函 数 可 以 拥有 多 个 不 同 的 状态 ， 在 特 
定 的 状态 下 ， 可 以 对 同一 消息 进行 不 同 的 处 理 ， 状 态 之 间 也 可 以 任意 切 
换 。 





现在 让 我 们 模拟 一 个 婴儿 Actor， 假 设 婴 儿 会 拥有 两 种 不 同 的 状 
态 ， 开 心 或 者 生气 。 当 你 带 他 玩 的 时 候 ， 他 总 是 会 表现 出 开心 状态 ， 当 
你 让 他 睡 沉 时， 他 就 会 非常 生气 ， 小 孩子 总 是 拥有 用 不 完 的 精力 ， 入 睡 
困难 可 能 是 一 种 通病 吧 ! 





在 我 们 这 个 简单 的 场景 模拟 中 ， 我 们 会 给 这 个 仙 儿 Actor 发 送 睡觉 
和 玩 两 种 指令 。 如 有 果 跟 儿 正在 生气 ， 你 还 让 他 睡觉 ， 他 就 会 说 “我 已 经 
生气 了 ”， 如 果 你 让 他 去 玩 ， 他 就 会 变 得 开心 起 来 。 同 样 ， 如 果 他 正 玩 
得 高 兴 ， 你 让 他 继续 玩 ， 他 就 会 说 “我 已 经 很 愉快 了 ”， 如 果 让 他 睡觉 ， 
他 就 马上 变 得 很 生气 。 


下 面 的 这 个 BabyActor 就 模拟 了 上 述 场景 : 


01 public class BabyActor extends UntypedActor { 


02 private final LoggingAdapter log = Logging.getLogger(getCo 
03 public static enum Msg { 
04 SLEEP, PLAY, CLOSE; 


05 } 


06 
07 
08 
09 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 
32 


Procedure<Object> angry = new Procedure<Object>() { 
@Override 
public void apply(Object message) { 
System.out.println("angryApply:"+message) ; 
if (message == Msg.SLEEP) { 
getSender().tell("I am already angry", getSelf 
System.out.printin("I am already angry"); 
} else if (message == Msg.PLAY) { 
System.out.printin("I like playing"); 
getContext().become(happy); 


i 


Procedure<Object> happy = new Procedure<Object>() { 
@Override 
public void apply(Object message) { 
System.out.printin("happyApply:'"+message) ; 
if (message == Msg.PLAY) { 
getSender().tell("I am already happy :-)", get 
System.out.printin("I am already happy :-)"); 
} else if (message == Msg.SLEEP) { 
System.out.printin("I don't want to sleep"); 


getContext().become(angry); 


33 


34 

35 @Override 

36 public void onReceive(Object msg) { 
37 System.out.printin("onReceive:'"+msg); 
38 if (msg == Msg.SLEEP) { 

39 getContext().become(angry); 
40 } else if (msg == Msg.PLAY) { 
41 getContext().become(happy); 
42 } else { 

43 unhandled(msg); 

44 } 

45 } 

46 } 


上 述 代 码 中 ， 使 用 了 become() 方 法 用 于 切换 Actor 的 状态 (第 39、41 
行 )。 方 法 become() 接 收 一 个 Procedure 参 数 。Procedure 在 这 里 可 以 表示 
一 种 Actor 的 状态 ， 同 时 ， 更 重要 的 是 它 封 装 了 在 这 种 状态 下 的 消息 处 
理 逻 辑 。 


在 这 个 BabyActor 中 ， 定 义 了 两 种 Procedure， 一 是 angry 生 气 (第 7 
行 )， 男 一 个 是 happy 开 心 ( 第 21 行 )。 


在 初始 状态 下 ，BabyActor 既 没有 生气 也 不 开心 。 因 此 angry 处 理 函 
数 和 happy 处 理 函 数 都 不 会 工作 。 当 BabyActor 接 收 到 消息 时 ， 系 统 会 调 
用 onReceive() 方 法 来 处 理 这 个 消息 。 


令 人 吃惊 的 麻 法 就 在 这 个 onReceive() 函 数 中 。 当 onReceive(0) 处 理 


SLEEP 消息 时 ， 它 会 切换 当前 Actor 的 状态 为 angry〈 第 39 行 ) 。 如 果 是 
PLAY 消息 ， 则 切换 状态 为 happy。 


一 旦 完成 状态 切换 ， 
onReceiveO 函 数 处 理 了 。 


当 后 续 有 新 的 消息 送 达 时 ， 就 不 会 再 由 
由 于 angry 和 happy 本 里 就 是 消息 处 理 函 数 。 








此 ， 后 续 的 消息 束 直 接 交 由 当前 状态 处 理 (angry 或 者 happy) ， 从 而 很 
好 地 封装 了 Actor 的 多 个 不 同 处 理 逻 辑 。 


下 面 的 代码 辐 我 们 的 婴儿 Actor 发 送 了 几 条 PLAY 和 SLEEP 的 消息 : 


o Oo NN O OT FB ND FB 


其 输出 如 下 (进行 


onReceive:PLAY 
happyApply : SLEEP 

I don't want to sleep 
angryApply :PLAY 

I like playing 
happyApply : PLAY 


system.actorOf(Props. 
child.tell(BabyActor. 
child.tell(BabyActor. 
child.tell(BabyActor. 
child.tell(BabyActor. 


ActorSystem system = ActorSystem.create("become", ConfigFactory 


ActorRef child = system.actorOf(Props.create(BabyActor.class), 


create(WatchActor.class, child), "watcher" 
Msg.PLAY, ActorRef.noSender()); 
Msg.SLEEP, ActorRef.noSender()); 
Msg.PLAY, ActorRef.noSender()); 


Msg.PLAY, ActorRef.noSender()); 


child.tell(PoisonPill.getInstance(), ActorRef.noSender()); 


ERBI) : 


I am already happy :-) 
[INFO] [akka://become/user/watcher] akka://become/user/baby has te 


system 


可 以 看 到 ， 当 第 一 个 PLAY 消息 到 来 时 ， 是 由 onReceiveO 函 数 进行 
处 理 的 ， 在 onReceive0 中 ， 将 Actor 切 换 为 happy 状 态 。 因 此 ， 当 SLEEP 
消息 达到 时 ， 由 happy.applyO 函 数 处 理 ， 接 着 Actor 切 换 为 angry 状 态 。 当 
PLAY 消息 再 次 到 达 时 ， 由 angry.apply0O 函 数 处 理 。 由 此 可 见 ，Akka 为 
Actor 提 供 了 灵活 的 状态 切换 机 制 ， 处 于 不 同 状态 的 Actor 可 以 绑 定 不 同 
的 消息 处 理 函 数 进行 消息 处 理 ， 这 对 构造 结构 化 应 用 有 着 重要 的 帮助 。 





7.10 询问 模式 : Actor 中 的 Future 











由 于 Actor 之 间 都 是 通过 异步 消息 通信 的 。 当 你 发 送 一 条 消息 给 一 
个 Actor 后 ， 你 通常 只 能 等 待 Actor 的 返回 。 与 同步 方法 不 同 ， 在 你 发 送 
异步 消息 后 ， 接 受 消息 的 Actor 可 能 还 根本 来 不 及 处 理 你 的 消息 ， 而 调 
用 方 就 已 经 返回 了 。 


这 种 模式 与 我 们 之 前 提 到 的 Future 模 式 非常 相像 。 不 同 之 处 只 是 在 
传统 的 异步 调用 中 ， 我 们 进行 的 是 函数 调用 ， 但 在 这 里 ， 我 们 发 送 了 一 


RIH Eo 








因为 两 者 的 行为 方式 是 如 此 相像 ， 因 此 我 们 就 会 很 自然 地 想到 ， 妆 
我 们 需要 一 个 有 返回 值 的 调用 时 ，Actor 是 不 是 也 应 该 给 我 们 一 个 契约 
(Future) W? Pe, MARIA PICA INE ve BURR Actor ity Mb EE i 
果 ， 在 将 来 ， 通 过 这 个 契约 还 是 可 以 追踪 到 我 们 的 请 求 的 。 





01 import static akka.pattern.Patterns.ask; 
02 import static akka.pattern.Patterns.pipe; 
03 


04 public class AskMain { 


05 

06 public static void main(String[] args) throws Exception { 
07 ActorSystem system = ActorSystem.create("askdemo", Con 
08 ActorRef worker = system.actorOf(Props.create(MyWorker 
09 ActorRef printer = system.actorOf(Props.create(Printer 


10 system.actorOf(Props.create(WatchActor.class, worker), 


12 // 等 待 future 返回 

13 Future<Object> f = ask(worker, 5, 1500); 

14 int re = (int) Await.result(f, Duration.create(6, Time 
15 System.out.printin("return:" + re); 

16 

17 // 直 接 导 向 其 他 Actor，pipe 不 会 等 待 

18 f = ask(worker, 6, 1500); 

19 pipe(f, system.dispatcher()).to(printer); 

20 

21 worker.tell(PoisonPill.getInstance(), ActorRef.noSende 
22 } 

23 } 


上 述 代码 给 出 了 两 处 在 Actor 交 互 中 使 用 Future 的 例子 。 





在 第 13 行 ， 使 用 ask() 方 法 给 worker 发 送 消息 ， 消 息 内 容 是 5， 也 就 
说 worker 会 接收 到 一 个 Integer 消 息 ， 值 为 5。 当 workder 接 收 到 消息 后 ， 
就 可 以 进行 计算 处 理 ， 并 且 将 结果 返回 给 发 送 者 。 当 然 ， 这 个 处 理 过 程 
可 能 需要 花费 一 点 时 间 。 

方法 ask0) 不 会 等 竺 worker 处 理 ， 会 立即 返回 一 个 Future 对 象 〈 第 13 


ÍT) 。 在 第 14 行 ， 我 们 使 用 Await 方 法 等 待 worker 的 返回 ， 接 着 在 第 15 
行 打印 返回 结果 。 





在 这 种 方法 中 ， 我 们 间接 地 将 一 个 异步 调用 转 为 同步 阻塞 调用 。 虽 
然 比较 容易 理解 ， 但 是 在 有 些 场合 可 能 会 出 现 性 能 问题 。 男 外 一 种 更 为 
有 效 的 方法 是 使 用 pipe(0) 函 数 。 








代码 第 18 行 使 用 askO 再 次 询问 worker， 并 传递 数值 6 给 worker。 接 着 
并 不 进行 等 待 ， 而 是 使 用 pipe0 将 这 个 Future 重 定 同 到 另外 一 个 称 为 
printer 的 Actor。pipeO 函 数 不 会 阻塞 程序 ， 会 立即 返回 。 


这 个 printer 的 实现 很 简单 的 ， 只 是 简单 地 输出 得 到 的 数据 : 


01 @Override 


02 public void onReceive(Object msg) { 


03 if (msg instanceof Integer) { 

04 System.out.printin("Printer:"+msg); 
05 } 

06 if (msg == Msg.DONE) { 

07 log.info("Stop working"); 

08 }if (msg == Msg.CLOSE) { 

09 log.info("I will shutdown"); 

10 getSender().tell(Msg.CLOSE, getSelf()); 
11 getContext().stop(getSelf()); 

12 } else 

13 unhandled(msg); 

14 } 


上 述 代 码 就 是 Printer Actor 的 实现 ， 它 会 通过 pipe(0) 方 法 得 到 worker 
的 输出 结果 ， 并 打印 在 控制 台 上 (第 4 行 )。 


在 本 例 中 ，worker Actor 接 受 一 个 整数 ， 并 计算 它 的 平方 ， 并 给 予 
返回 。 如 下 : 


01 @Override 


02 public void onReceive(Object msg) { 


03 if (msg instanceof Integer) { 

04 int i=(Integer)msg; 

05 try { 

06 Thread.sleep(1000); 

07 } catch (InterruptedException e) {} 
08 getSender().tell(i*i, getSelf()); 
09 } 

10 if (msg == Msg.DONE) { 

tic log.info("Stop working"); 

12 }if (msg == Msg.CLOSE) { 

TS log.info("I will shutdown"); 

14 getSender().tell(Msg.CLOSE, getSelf()); 
15 getContext().stop(getSelf()); 

16 } else 

17 unhandled(msg); 

18 } 


上 上述 代码 第 5 一 7 行 ， 模 拟 了 一 个 耗 时 的 调用 ， 为 了 更 明显 地 说 明 
ask() 和 pipe() 方 法 的 用 途 。 第 8 行 ，worker 计 算 了 给 定数 值 的 平方 ， 并 把 
它 “ 告 诉 ” 请 求 者 。 


7.11 多 个 Actor 同 时 修改 数据 : 
Agent 


在 Actor 的 编程 模型 中 ，Actor 之 间 主 要 通过 消息 进行 信息 传递 。 
此 ， 很 少 发 生 多 个 Actor 需 要 访问 同一 个 共 孚 变量 的 情况 。 但 在 实际 开 
发 中 ， 这 种 情况 很 难 完全 避免 。 那 如 果 多 个 Agent 需 要 对 同一 个 共 译 变 
量 进行 读 写 时 ， 如 何 保 证 线程 安全 呢 ? 


在 Akka 中 ， 使 用 一 种 叫做 Agent 的 组 件 来 实现 这 个 功能 。 一 个 Agent 
提供 了 对 一 个 变量 的 异步 更 新 。 当 一 个 Actor 希 望 改变 Agent 的 值 时 ， 它 
会 向 这 个 Agent 下 发 一 个 动作 〈action) 。 当 多 个 Actor 同 时 改变 Agent 
时 ， 这 些 action 将 会 在 ExecutionContext 中 被 并 发 调度 执行 。 在 任意 时 
刻 ， 一 个 Agent 最 多 只 能 执行 一 个 action， 对 于 某 一 个 线程 来 说 ， 它 执行 
action 的 顺序 与 它 的 发 生 顺 序 一 致 ， 但 对 于 不 同 线程 来 说 ， 这 些 action 可 
能 会 交织 在 一 起 。 





Agent 的 修改 可 以 使 用 两 个 方法 send0) 或 者 alter0)。 它 们 都 可 以 同 
Agent 发 送 一 个 修改 动作 。 但 是 send() 方 法 没有 返回 值 ， 而 alter0 方 法 会 
返回 一 个 Future 对 象 便 于 跟踪 Agent 的 执行 。 


下 面 让 我 们 模拟 这 么 一 个 场景 : 有 10 个 Actor， 它 们 一 起 对 一 个 
Agent 执 行 累加 操作 ， 每 个 agent 累 加 10000 次 ， 如 果 没 有 意外 ， 那 么 
agent 最 终 的 值 将 是 100000， 如 果 Actor 间 的 调度 出 现 问题 ， 那 么 这 个 值 
可 能 小 于 100000。 


01 public class CounterActor extends UntypedActor { 


02 Mapper addMapper = new Mapper<Integer, Integer>() { 





03 @Override 

04 public Integer apply(Integer i) { 

05 return i+1; 

06 } 

07 3; 

08 

09 @Override 

10 public void onReceive(Object msg) { 

11 if (msg instanceof Integer) { 

12 for (int i = 0; i < 10000; i++) { 
13 // 我 希望 能 够 知道 future 何 时 结束 

14 Future<Integer> f = AgentDemo.counterAgent.al 
15 AgentDemo.futures.add(f); 

16 } 

Ly getContext().stop(getSelf()); 

18 } else 

19 unhandled(msg); 

20 } 

21 } 


上 述 代码 定义 了 一 个 累加 的 Actor: CounterActor。 第 2 一 7 行 ， 定 义 
了 款 计 动作 action addMapper。 它 的 作用 是 对 Agent 的 值 进行 修改 ， 这 里 
简单 地 加 1。 


CounterActor 的 消息 处 理 函 数 onReceive0 中 ， 对 全 局 的 counterAgent 
进行 累加 操作 ，alter0 指 定 了 味 加 动作 addMapper〈 第 14 行 ) 。 由 于 我 们 


希望 在 将 来 知道 囚 加 行为 是 否 完成 ， 因 此 在 这 里 将 返回 的 Future 对 象 进 
ITAR (第 15 行 )。 完 成 任务 后 ，Actor 自 行 退 出 (第 17 行 ) 。 


程序 的 主 函 数 如 下 : 
01 public class AgentDemo { 
02 public static Agent<Integer> counterAgent = Agent.create( 
03 static ConcurrentLinkedQueue<Future<Integer>> futures = 


<Integer>>(); 








04 
05 public static void main(String[] args) throws InterruptedE 
06 final ActorSystem system = ActorSystem.create("agentde 
07 ConfigFactory.load("samplehello.conf")); 

08 ActorRef[] counter = new ActorRef [10]; 

09 for (int i = 0; i < counter.length; i++) { 

10 counter[i] = system.actorOf(Props.create(CounterAc 
11 } 

12 final Inbox inbox = Inbox.create(system) ; 

13 for (int i = 0; i < counter.length; i++) { 

14 inbox.send(counter[i], 1); 

aS inbox.watch(counter[i]); 

16 } 

17 

18 int closeCount = 0; 

19 // 等 待 所 有 Actor 全 部 结束 

20 while (true) { 


21 Object msg = inbox.receive(Duration.create(1, Time 


if (msg instanceof Terminated) { 
closeCount++; 
if (closeCount == counter.length) { 
break; 
} 
} else { 


System.out.println(msg) ; 


} 
// 等 待 所 有 的 累加 线程 完成 , 因为 他 们 都 是 异步 的 


Futures.sequence(futures, system.dispatcher()).onCompl 





new OnComplete<Iterable<Integer>>() { 
@Override 
public void onComplete(Throwable argQO, Ite 
System.out.printin("counterAgent=" + c 
system.shutdown(); 


} 
}, system.dispatcher()); 


上 述 代 码 中 ， 第 8 一 11 行 ， 创 建 了 10 个 CounterActor 对 象 。 第 12 一 16 


行 ， 使 用 Inbox 与 CounterActor 进 行 通信 。 第 14 行 的 消息 将 触发 
CounterActor 进 行 累加 操作 。 第 20 一 30 行 系统 将 等 竺 所 有 10 个 
CounterActor 运 行 结束 。 执 行 完 成 后 ， 我 们 便 已 经 收集 了 所 有 的 Future。 
在 第 32 行 ， 将 所 有 的 Future 进 行 串 行 组 合 ( 使 用 sequence() 方 法 ) ， 构 造 
了 一 个 整体 的 Future， 并 为 它 创 建 onComplete0) 回 调 函 数 。 在 所 有 的 


Agent 操 作 执 行 完 成 后 ，onComplete(0) 方 法 就 会 被 调用 《第 35 行 ) 。 在 这 
个 例子 中 ， 我 们 简单 地 输出 最 终 的 counterAgent 值 〈 第 36 行 ) ， 并 关闭 
系统 《第 37 行 ) 。 


执行 上 述 程序 ， 我 们 将 看 到 : 


counterAgent=100000 


7.12 像 数 据 库 一 样 操作 内 存 数 
Wi: WEES AT 


在 一 些 函 数 式 编程 语言 中 ， 文 持 一 种 叫做 软件 事务 内 存 CSTM) 的 
技术 。 什 么 是 软件 事务 内 存 呢 ? 这 里 的 事务 和 数据 库 中 所 说 的 事务 非常 
类 似 ， 具 有 隔离 性 、 原 子 性 和 一 致 性 。 与 数据 库 事 务 不 同 的 是 ， 内 存 事 
务 不 具备 持久 性 《很 显然 内 存 数据 不 会 保存 下 来 ) 。 








在 很 多 场合 ， 某 一 项 工作 可 能 要 由 多 个 Actor 协 作 完成 。 在 这 种 协 
作 事 务 中 ， 如 果 一 个 Actor 处 理 失 败 ， 那 么 根据 事务 的 原子 性 ， 其 他 
Actor 所 进行 的 操作 必须 要 回 滚 。 下 面 ， 就 让 我 们 来 看 一 个 简单 的 案 
例 。 








假设 有 一 个 公司 要 给 他 的 员工 发 放 福 利 ， 公 司 账户 里 有 100 元 。 
次 ， 公 司 账户 会 给 员工 账户 转 一 笔 钱 ， 假 设 转账 10 元 ， 那 么 公司 账户 中 
应 该 减 去 10 元 ， 同 时 ， 员 工 账户 中 应 该 增加 10 元 。 这 两 个 操作 必须 同时 
完成 ， 或 者 同时 不 完成 。 











首先 ， 让 我 们 看 一 下 主 函数 中 是 如 何 局 动 一 个 内 存 事务 的 : 


01 public class STMDemo { 


02 public static ActorRef company=null1; 

03 public static ActorRef employee=null; 

04 

05 public static void main(String[] args) throws Exception { 


06 final ActorSystem system = ActorSystem.create("transactionDemo 


("samplehello.conf")); 


07 company=system.actorOf(Props.create(CompanyActor.class 
08 employee=system.actorOf(Props.create(EmployeeActor.cla 
09 

10 Timeout timeout = new Timeout(1, TimeUnit.SECONDS); 

11 

12 for(int 1=1;1<20;it++){ 

13 company.tell(new Coordinated(i, timeout), ActorRef 
14 Thread.sleep(200) ; 

15 Integer companyCount = (Integer) Await.result( 

16 ask(company, "GetCount", timeout), timeout 
17 Integer employeeCount = (Integer) Await.result( 

18 ask(employee, "GetCount", timeout), timeou 
19 

20 System.out.println("company count="+companyCount ) ; 
21 System.out.println( "employee count="+employeeCount 
22 System.out.println("================="); 

23 } 

24 } 

25 } 





上 述 代 码 中 CompanyActor 和 EmployeeActor 分 别 用 于 管理 公司 账户 
OE ARE o HER T 23TH, BAT SARTO, FA 次 汇款 额 
度 为 1 元 ， 第 二 次 为 2 元 ， 依 此 类 推 ， 最 后 一 笔 汇 款 为 19 元 。 


在 第 13 行 ， 新 建 一 个 Coordinated 协 调 者 ， 并 且 将 这 ee ee 
AR company. “company k Ehx Mi ai Ba, H ~A 


事务 的 第 一 个 成 员 。 


第 15 一 18 行 询问 公司 账户 和 雇员 账户 的 当前 余额 ， 并 在 第 20 一 21 行 
进行 输出 。 


下 面 是 代表 公司 账户 的 Actor: 


01 public class CompanyActor extends UntypedActor { 


02 private Ref.View<Integer> count = STM.newRef (100); 

03 

04 @Override 

05 public void onReceive(Object msg) { 

06 if (msg instanceof Coordinated) { 

07 final Coordinated c=(Coordinated)msg; 

08 final int downCount=(Integer )c.getMessage(); 

09 STMDemo.employee.tell(c.coordinate(downCount), get 
10 try{ 

11 c.atomic(new Runnable() { 

12 @Override 

13 public void run() { 

14 if (count.get()<downCount ) { 

15 throw new RuntimeException("less t 
16 } 

17 STM.increment(count, -downCount); 

18 } 

19 }); 

20 }catch(Exception e){ 


21 e.printStackTrace(); 


23 

24 }else if ("GetCount".equals(msg)) { 

25 getSender().tell(count.get(), getSelf()); 
26 selse{ 

27 unhandled(msg); 

28 } 

29 } 

30 } 


在 CompanyActor 中 ， 首 先 判断 接收 的 msg 是 否 是 Coordinated。 如 果 
是 Coordinated， 则 表示 这 是 一 个 新 事务 的 开始 。 在 第 8 行 ， 获 得 事务 的 
参数 也 就 是 需要 转账 的 金额 。 接 着 在 第 9 行 ， 将 调用 
Coordinated.coordinate() 方 法 ， 将 employee 也 加 入 到 当前 事务 中 ， 这 样 这 
个 事务 中 就 有 两 个 参与 者 了 。 


第 11 行 ， 调 用 了 Coordinated.atomicO 定 义 了 原子 执行 块 作 为 这 个 事 
务 的 一 部 分 。 在 这 个 执行 块 中 ， 对 公司 账户 进行 余额 调整 〈 第 17 行 ) 。 
但 是 当 汇 款额 度 大 于 可 用 余额 时 ， 就 会 抛 出 异常 ， 宣 告 失败 。 


第 25 行 用 于 处 理 GetCount 消 息 ， 返 回 当前 账户 余额 。 





作为 转账 接收 方 的 雇员 账户 如 下 : 


01 public class EmployeeActor extends UntypedActor { 
02 private Ref.View<Integer> count = STM.newRef(50); 
03 


04 @Override 


05 public void onReceive(Object msg) { 


06 if (msg instanceof Coordinated) { 

07 final Coordinated c = (Coordinated) msg; 

08 final int downCount = (Integer) c.getMessage(); 
09 try { 

10 c.atomic(new Runnable() { 

11 @Override 

12 public void run() { 

13 STM.increment(count, downCount); 
14 } 

15 }); 

16 } catch (Exception e) { 

17 } 

18 } else if ("GetCount".equals(msg)) { 

19 getSender().tell(count.get(), getSelf()); 

20 } else { 

21 unhandled(msg); 

22 } 

23 } 

24 } 


上 述 代码 第 2 行 ， 设 置 雇员 账户 初始 金额 是 50 元 。 第 6 行 ， 判 断 消 
是 否 为 Coordinated， 如 果 是 Coordinated， 则 当前 Actor 会 自动 加 入 
Coordinated 指 定 的 事务 。 第 10 行 ， 定 义 原子 操作 ， 在 这 个 操作 中 将 修改 
雇员 账户 余额 。 在 这 里 ， 我 们 并 没有 给 出 异常 情况 的 判断 ， 只 要 接收 到 
转 入 金额 ， 一 律 将 其 增加 到 雇员 账户 中 。 





大 家 可 能 就 会 产生 疑问 ， 如 有 果 在 公司 账户 中 由 于 余额 不 足 而 导致 转 
账 失 败 了 ， 那 在 这 个 雇员 账户 中 不 还 是 正常 增加 了 金额 吗 ? 那 吕 不 是 钱 
多 出 来 了 ? 





不 过 这 个 担心 是 完全 多 余 的 。 因 为 在 这 里 ， 两 个 Actor 都 已 经 加 入 
到 同一 个 协调 事务 Coordinated 中 了 ， 因 此 当 公 司 账 户 出 现 异 党 后， 雇员 
WKF AAS AU LTR 


执行 上 述 程序 ， 部 分 输出 如 下 : 


company count=85 
employee count=65 


java.lang.RuntimeException: less than 14 
company count=9 


employee count=141 


java.lang.RuntimeException: less than 19 

省 略 堆栈 信息 实在 太 多 了 

at scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoi 
company count=9 
employee count=141 
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务 内 存 的 作用 。 


7.13 一 个 有 趣 的 例子 : 并 发 粒子 
群 的 实现 


粒子 群 算法 (PSO)〉 是 一 种 进化 算法 。 它 与 大 名 蜀 克 的 遗传 算法 非 
党 类似， 可 以 用 来 解决 一 些 优化 问题 。 大 家 知道 ， 一 些 优化 问题 〈 比 如 
旅行 商 问题 TSP) 都 属于 NP 问 题 。 它 们 的 时 间 复 杂 度 可 能 会 达到 On) 
或 者 O(2”)， 这 种 在 多 项 式 时 间 内 不 可 解 的 问题 总 是 会 让 人 望 而 生 长 。 
而 以 PSO 算 法 为 代表 的 进化 计算 ， 往 往 可 以 将 这 些 NP 问 题 ， 转 变 为 一 个 
多 项 式 问题 。 但 这 种 转变 是 有 代价 的 ， 进 化 算法 往往 都 不 保证 你 可 以 从 
结果 中 得 到 最 优 解 。 我 这 么 说 ， 也 许 就 有 人 会 问 了 ， 这 个 算法 都 不 能 保 
证 得 到 最 优 解 ， 那 有 什么 用 呢 ? 其 实 ， 在 生活 中 的 很 多 场景 下 ， 并 不 是 
特别 需要 最 优 解 ， 我 们 更 加 希望 得 到 的 是 一 个 满意 解 。 比 如 说 ， 去 水 果 
店 买 西 瓜 ， 店 里 可 能 放 着 一 大 推 西瓜 ， 每 个 人 都 想 挑 一 个 最 好 的 。 但 你 
想 拿 到 最 好 的 那个 西瓜 必须 得 挨个 检查 过 去 ， 并 且 还 得 认真 做 好 记录 才 
行 。 我 相信 ， 没 有 一 个 人 会 这 么 买 西瓜 ， 因 为 成 本 太 高 了 。 对 于 大 部 分 
人 来 说 ， 更 倾向 于 在 表面 上 挑 几 个 顺眼 的 看 看 ， 如 果 还 过 得 去 ， 也 就 下 
手 了 。 这 也 就 是 说 只 要 这 个 结果 不 要 差 得 太 离谱 就 行 了 。 




















既然 最 优 的 方案 很 难得 到 ， 那 么 我 们 束 想 办 法 以 很 低 的 成 本 获得 一 
个 还 算 过 得 去 的 方案 ， 也 不 失 为 一 计 良 策 。 在 后 面 给 出 的 小 案例 中 大 家 
也 可 以 看 到 ， 在 很 多 情况 下 ， 虽 然 进 化 算法 无 法 让 你 获得 最 优 解 ， 也 无 
法 证 明 它 得 到 的 解 与 最 优 解 到 确 有 多 少 差 距 ， 但 实际 中 ， 通 过 进化 算法 
搜索 到 的 满意 解 很 可 能 与 最 优 解 已 经 非常 接近 了 。 











7.13.1 什么 是 粒子 群 算法 


粒子 群 优化 算法 (PSO〉 是 一 种 进化 计算 技术 ， 最 早 由 Kenny 与 
Eberhart 于 1995 年 提出 。 它 源 于 对 乌 群 捕食 行为 的 研究 ， 与 遗传 算法 相 
似 ， 是 一 种 基于 迭代 的 优化 算法 ， 广 泛 应 用 于 函数 优化 和 神经 网 络 训练 
等 方面 。 与 遗传 算法 相 比 ，PSO 算 法 的 实现 简单 得 多 ， 人 参数 配置 也 相对 
较 少 ， 对 使 用 人 员 的 经 验 要 求 不 高 ， 因 此 更 加 易于 实际 工程 应 用 。 

















从 日 第 生活 的 观察 中 可 以 知道 ， 马 类 的 竟 食 往往 会 表现 成 群体 特 
性 。 如 果 在 地 上 有 一 小 摄食 物 ， 那 么 乌 群 很 可 能 就 会 聚集 在 这 一 堆 食物 
旁边 。 如 果 其 中 一 只 小 乌 发 现 了 男 外 一 堆 更 丰盛 的 食物 ， 那 它 可 能 会 离 
群 飞 癌 更 直 右 的 食物 ， 而 这 有 可 能 带动 整个 乌 群 一 起 飞 同 新 的 地 点 。 妆 
然 了 ， 在 整个 种 群 中 ， 难 免 会 出 现 几 只 特别 有 “个 性 ”的 小 鸟 ， 它 们 不 于 
欢 太 热闹 的 地 方 ， 当 整个 种 群 迁移 时 ， 它 们 不 会 跟着 种 群 走 ， 或 者 自己 
散步 ， 或 者 自行 游 沪 。 





粒子 群 算 法 正 是 对 上 述 过 程 的 模拟 。 在 程序 中 ， 我 们 可 以 模拟 大 量 
的 小 鸟 ， 小 鸟 的 况 食 点 正 是 要 求解 的 问题 的 解 。 解 越 是 优秀 ， 意 味 着 食 
物 越 是 丰盛 ， 因 此 ， 模 拟 的 小 乌 会 从 自己 的 位 置 出 发 以 一 定 的 速度 癌 最 
优点 的 方 同 移动 。 在 移动 过 程 中 ， 任 何 一 只 小 鸟 都 有 可 能 发 现 更 好 的 
解 ， 这 又 会 进一步 影响 群体 的 行为 。 就 这 样 如 此 反复 迭代 ， 最 终 ， 将 得 
到 一 个 不 错 的 答案 。 


7.13.2 ”粒子 群 算 法 的 计算 过 程 


粒子 群 算法 的 大 体 步 又 如 下 : 














1. 初始 化 所 有 粒子 ， 粒 子 的 位 置 随机 生成 。 计 算 每 个 粒子 当前 的 适 
应 度 ， 并 将 此 设 为 当前 粒子 的 个 体 最 优 值 〈 记 为 pPBest) 。 

2. 所 有 粒子 将 自己 的 个 体 最 优 值 发 送 给 管理 者 Master。Master 获 得 
所 有 镁 子 的 信息 后 ， 筛 选 出 全 局 最 优 的 解 〈 记 为 gBest) 。 

3.，IMaster 将 gBest 通 知 所 有 粒子 ， 所 有 粒子 便 知道 全 局 最 优点 的 位 
置 。 

4. 接着 ， 所 有 粒子 根据 自己 的 pBest 和 全 局 gBest， 更 新 自己 的 速 
度 ， 在 有 了 速度 后 ， 再 更 新 目 己 的 位 置 。 


Vk+r1=Ccoxrand(OxvVk+clxrand()x(pbestl-XlJ+c2xrand(Ox(gbest 一 Xo) 





Xk+1—Xkt Vk+1 
其 中 ，rand0 函 数 产生 一 个 0，1 之 间 的 随即 数 。co=1，ci=2， 
co=2，k 表 示 进 化 的 代数 。Vi 表 示 当 前 速度 ，pbest, 和 gbest, 表 示 
个 体 最 优 解 和 全 局 最 优 解 。 当 然 ， 对 于 每 一 个 维度 上 的 速度 分 
量 ， 我 们 可 以 为 它 限 定 一 个 最 大 值 。 确 保 * 小 乌 ? 不 会 飞 得 太 快 ， 
关 过 了 重要 的 信息 。 

5. 如 果 粒 子 产 生 了 新 的 个 体 最 优点 ， 则 发 送 给 Master， 在 此 ， 转 到 


步骤 2。 

















整体 过 程 的 示意 图 如 图 7.2 所 示 。 
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图 7-2 PS0 算 法 示意 图 











从 这 个 计算 步骤 中 可 以 看 到 ， 计 算 过 程 拥 有 一 定 的 随机 性 。 但 由 于 
我 们 可 以 局 用 大 量 的 例子 ， 因 此 其 计算 效果 在 统计 学 意义 上 是 稳定 的 。 
在 这 个 标准 的 粒子 群 算法 中 ， 由 于 所 有 粒子 都 会 癌 全 局 最 优 靠拢 ， 因 
此 ， 其 跳出 局 部 最 优 的 能 力 并 不 算 太 强 。 因 此 ， 我 们 也 可 以 想 办 法 对 标 
准 的 粒子 群 算法 进行 一 些 合理 的 改进 。 比 如 ， 允 许 各 个 粒子 随机 移动 ， 
甚至 逆向 移动 来 试图 突破 局 部 最 优 。 在 这 里 为 简单 起 见 ， 我 不 打算 做 这 
些 复杂 的 实现 。 


7.13.3 ”粒子 群 算法 能 做 什么 


粒子 群 算 法 能 为 我 们 做 些 什么 呢 ? 它 应 用 最 多 的 场景 是 进行 最 优化 
计算 。 实 际 上 ， 以 粒子 群 算法 为 代表 的 进化 计算 ， 可 以 说 是 最 优化 方法 
中 的 通用 方法 。 几 乎 一 切 最 优化 问题 都 可 以 通过 这 种 随机 搜索 的 模式 解 
决 ， 其 成 本 低 、 难 度 小 、 效 果 好 ， 因 此 烦 受 欢迎 。 








下 面 ， 束 让 我 们 来 探讨 一 个 典型 的 优化 问题 : 


假设 现在 有 400 万 资金 ， 要 求 4 年 内 使 用 完 。 大 在 第 1 年 使 用 x 万 元 ， 
则 可 以 得 到 效益 Vx 万 元 (效益 不 能 再 使 用 ) ， 当 年 不 用 的 资金 可 存 入 
银行 ， 年 利率 为 10%。 尝 试制 订 出 资金 的 使 用 规划 ， 使 4 年 效益 之 和 最 
大 。 





很 明显 ， 对 于 这 类 问题 ， 不 同 的 方案 得 到 的 结果 可 能 会 有 很 大 的 差 
异 。 比 如 ， 车 第 一 年 把 400 万 元 全 部 用 完 ， 则 总 效益 为 400 =20 万 元 ; 
若 前 3 年 均 不 用 而 存 入 银行 ， 第 4 年 把 本 金 和 利息 全 部 用 完 ， 则 总 效益 为 
万 元 ， 显 然 优 于 第 一 种 方案 。 





如 果 我 们 将 此 问题 转 为 一 般 化 的 优化 问题 ， 则 可 以 得 到 以 下 方程 
组 ， 如 图 7.3 所 示 。 


Mon 之 二 | 入， + NX, 十 MX + jw 
St. Xs ho 
) /XN < LOD 
|.21K , +IX Ph E 4u 
1.23%, + 121N +t) /XX 932.4 


Xe > Xs Xa 70 
图 7. 3 一般 化 的 约束 问题 


其 中 ，x1、x2、x3、x4 分 别 表示 第 1、2、3、4 年 使 用 的 资金 。 使 用 
拉 格 朗 日 乘 子 法 对 此 方程 组 进行 求解 ， 可 以 得 到 第 一 年 使 用 86.19 万 
元 、 第 2 年 使 用 104.29 万 元 ， 第 3 年 使 用 126.19 万 元 ， 第 4 年 使 用 152.69 万 
元 为 这 个 问题 的 最 优 解 ， 此 时 总 效益 达 43.09 万 元 。 





由 于 求解 过 程 过 于 复杂 ， 使 用 拉 格 明日 乘 子 法 时 ， 需 要 对 先后 12 个 


未 知 数 和 方程 进行 联 立 求解 ， 比 较 难以 实现 。 由 于 求解 过 程 与 我 们 讨论 
的 主题 无 天 ， 所 以 在 这 里 不 再 给 出 。 


对 于 类 似 的 优化 问题 ， 正 是 粒子 群 算法 的 涉猎 范围 。 当 使 用 粒子 群 
算法 时 ， 我 们 可 以 先 随机 给 出 耕 干 个 满足 提交 的 资金 规划 方 采 。 接 着 ， 
根据 粒子 群 的 演化 公式 ， 不 断 调整 各 个 粒子 的 位 置 ( 粒 子 的 每 一 个 位 置 
代表 一 套 方案 ) ， 逐 步 探索 更 优 的 方案 。 


7.13.4 ”使 用 Akka 实 现 粒 子 群 


现在 ， 我 们 已 经 知道 粒子 群 的 原理 ， 并 且 有 了 一 个 较为 复杂 的 优化 
问题 等 等 我 们 求解 。 接 下 来 ， 束 需要 开动 脑筋 ， 使 用 Akka 来 实现 一 个 简 
单 的 粒子 群 ， 来 解决 这 个 优化 问题 了 。 








使 用 Actor 的 模式 与 粒子 群 算 法 之 间 有 着 天 生 切 合 度 。 粒 子 群 算法 
由 于 涉及 到 多 个 甚至 是 极其 大 量 的 粒子 参与 运算 ， 因 此 它 隐 含 着 并 行 计 
算 的 模式 。 其 次 ， 从 直观 上 我 们 也 可 以 知道 ， 粒 子 群 算法 的 求解 精度 或 
者 说 求解 的 质量 ， 与 参与 运算 的 粒子 有 着 直接 的 关系 。 很 显然 ， 参 与 运 
算 的 粒子 数量 越 多 ， 得 到 的 解 自然 也 束 越 精确 。 











如 果 我 们 使 用 传统 的 多 线程 方式 实现 粒子 群 ， 一 个 最 大 的 问题 就 是 
线程 的 数量 可 能 是 非常 有 限 的 。 在 当前 这 种 应 用 场景 中 ， 我 们 希望 可 以 
拥有 数 万 ， 甚 至 数 十 万 的 粒子 ， 以 提高 计算 精度 ， 但 众所周知 ， 在 一 台 
计算 机 上 运行 数 万 个 线程 基本 是 不 可 能 的 ， 就 算 可 以 ， 系 统 的 性 能 也 会 
大 打折 扣 。 因 此 ， 使 用 多 线程 的 模型 无 法 很 好 地 和 粒子 群 的 实现 相 融 


A 
Ho 





但 Akka 的 Actor 的 模型 则 不 同 。 由 于 多 个 Actor 可 以 复 用 一 个 线程 ， 
而 Actor 本 里 作为 轻 量 级 的 并 发 执行 单元 可 以 有 极其 大 量 的 存在 。 
此 ， 我 们 就 可 以 使 用 Actor 来 模拟 整个 粒子 群 计算 的 场景 。 下 面 就 让 我 
们 仔细 看 一 下 系统 的 实现 。 














首先 ， 我 们 需要 两 个 表示 pBest 和 gBest 的 消息 类 型 ， 用 于 在 多 个 
Actor 之 间 传 递 个 体 最 优 和 全 局 最 优 。 


01 public final class GBestMsg { 


02 final PsoValue value; 

03 public GBestMsg(PsoValue v){ 
04 value=v; 

05 } 

06 public PsoValue getValue() { 
07 return value; 

08 } 

09 } 

10 


11 public final class PBestMsg { 


12 final PsoValue value; 

13 public PBestMsg(PsoValue v){ 
14 value=v; 

15 } 

16 

17 public PsoValue getValue() { 
18 return value; 


19 } 


21 public String toString(){ 
22 return value.toString(); 
23 } 

24 } 








上 述 代 码 中 ，GBestMsg《〈 代 码 第 1 行 ) 表示 携带 全 局 最 优 解 的 消 
上 息 。 而 PBestMsg〈 代 码 第 11 行 ) 表示 携带 个 体 最 优 的 消息 。 它 们 都 使 用 
PsoValue 来 表示 一 个 可 行 的 解 。 


在 PsoValue 中 ， 主 要 包括 两 个 信息 ， 第 一 是 表示 投资 规划 的 方案 ， 
即 每 一 年 分 别 需 要 投资 多 少 钱 ; 第 二 是 这 个 投资 方案 的 总 收益 : 


01 public final class PsoValue { 


02 final double value; 

03 final List<Double> x; 

04 public PsoValue(double v,List<Double> x){ 
05 value=v; 

06 List<Double> b=new ArrayList<Double>(5); 
07 b.addAll(x); 

08 this.x=Collections.unmodifiableList(b); 
09 } 

10 public double getValue(){ 

aal return value; 

12 } 

13 public List<Double> getX(){ 

14 return x; 


15 } 


17 public String toString(){ 

18 StringBuffer sb=new StringBuffer(); 

19 sb.append("value:").append(value).append("\n" ) 
20 .append(x.toString()); 

21 return sb.toString(); 

22 } 

23 } 


上 述 代 码 中 ， 数 组 x 中 ，x[1]、x[2]、x[3]、x[4] 分 别 表 示 第 1 年 、 第 2 
年 、 第 3 年 和 第 4 年 的 投资 额 。 这 里 为 了 方便 起 匈 ， 我 忽略 了 x[0]〈 它 在 
我 们 的 程序 中 是 没有 作用 的 ) 。 成 员 变 量 value 表 示 这 组 投资 方案 的 收益 
值 。 











因此 ， 根 据 需 求 x 与 Value 之 间 的 关系 如 下 代码 所 示 : 


1 public class Fitness { 

2 public static double fitness(List<Double> x){ 
3 double sum=0; 

4 for(int 1=1;1i<x.size();i++){ 

5 sumt+=Math.sqrt(x.get(1)); 

6 i 

7 return sum; 

8 i 

9 } 


上 述 代码 定义 的 fitness() 函 数 返 回 了 给 定投 资方 末 的 适应 上 度 。 适 应 
度 也 就 是 投资 的 收益 ， 我 们 目 然 应 该 更 倾 问 于 选择 适应 度 更 高 的 投资 方 





案 。 在 这 里 适应 度 =Vxl + Vx2 +Vx3 +\Vx4。 


有 了 这 些 基础 工具 ， 我 们 就 可 以 来 实现 简单 的 粒子 〈 这 里 我 把 它 叫 
作 Bird) 了 。 


对 于 基本 粒子 ， 我 们 需要 定义 以 下 成 员 变 量 : 


public class Bird extends UntypedActor { 
private final LoggingAdapter log = Logging.getLogger(getCon 


private PsoValue pBest=null; 


al 

2 

3 

4 private PsoValue gBest=null; 

5 private List<Double> velocity =new ArrayList<Double>(5); 
6 private List<Double> x =new ArrayList<Double>(5); 

7 


private Random r = new Random(); 


上 述 代码 中 ，pBest 和 8gBest 分 别 表 示 个 体 最 优 和 全 局 最 优 ，velocity 
表示 粒子 在 各 个 维度 上 的 速度 〈 在 当前 案例 中 ， 每 一 年 的 投资 额 就 可 以 
认为 是 一 个 维度 ， 因 此 系统 有 4 个 维度 ) 。x 表 示 投 资方 案 ， 即 每 一 年 的 
投资 额 。 由 于 在 粒子 群 算法 中 ， 需 要 使 用 随机 数 ， 因 此 ， 这 里 定义 了 


To 











当 一 个 粒子 被 创建 时 ， 我 们 需要 初始 化 粒子 的 当前 位 置 。 粒 子 的 每 
一 个 位 置 都 代表 一 个 投资 方案 ， 下 面 的 代码 展示 了 粒子 的 初始 化 逻辑 : 








01 @Override 

02 public void preStart(){ 

03 for(int 1=0;1<5;i++){ 

04 velocity.add(Double.NEGATIVE_INFINITY); 
05 x.add(Double.NEGATIVE_INFINITY); 


06 } 


07 //X1<=400 

08 x.set(1, (double)r.nextInt(401) ); 

09 

10 //X2<=440-1.1*x1 

11 double max=400-1.1*x.get(1); 

12 if (max<0)max=0; 

13 x.set(2, r.nextDouble()*max); 

14 

15 MS ASAR Xd NY 

16 max=484-1.21*x.get(1)-1.1*x.get(2); 

17 if (max<=0)max=0; 

18 x.set(3, r.nextDouble()*max); 

19 

20 //X4<= 532.4-1.331*x1-1.21*x2-1.1*x3 
21 max=532.4-1.331*x.get(1)-1.21*x.get(2)-1.1*x.get(3); 
22 if (max<=0)max=0; 

23 x.set(4, r.nextDouble()*max); 

24 

25 double newFit=Fitness.fitness(x); 

26 pBest=new PsoValue(newFit, x); 

27 PBestMsg pBestMsg=new PBestMsg(pBest); 
28 ActorSelection selection = getContext().actorSelection("/u 
29 selection.tell(pBestMsg, getSelf()); 
30 } 


由 于 在 当前 案例 中 ， 每 一 年 的 投资 额度 是 有 条 件 约 束 的 ， 比 如 第 一 


年 的 投资 额 不 能 超过 400 万 《第 7 一 8 行 ) ， 而 第 2 年 的 投资 上 限 是 440 万 
(假设 第 一 年 全 部 存 银行 ， 代 码 第 10 一 13 行 ) ， 依 此 类 推 。 粒 子 初 始 化 
时 ， 随 机 生成 一 组 满足 基本 约束 条 件 的 投资 组 合 ， 并 计算 它 的 适应 度 

《第 25 行 ) 。 初 始 的 投资 方案 自然 也 束 作 为 当前 的 个 体 最 优 ， 并 发 送 给 
Master 〈 第 29 行 ) 。 








当 Master 计 算出 当前 全 局 最 优 后 ， 会 将 全 局 最 优 友 送 给 每 一 个 粒 
子 ， 粒 子 根据 全 局 最 优 更 新 自己 的 运行 速度 ， 并 更 新 自己 的 速度 以 及 当 
前 位 置 。 











01 @Override 


02 public void onReceive(Object msg) { 


03 if (msg instanceof GBestMsg) { 

04 gBest=((GBestMsg) msg).getValue(); 
05 // 更 新 速度 

06 for(int 1=1;i<velocity.size();i++){ 
07 updateVelocity(i); 

08 } 

09 // 更 新 位 置 

10 for(int i=1;1<x.size()jitt+){ 

11 updateX(1); 

12 } 

13 validateXx(); 

14 double newFit=Fitness.fitness(x); 
15 if (newFit >pBest.value) { 

16 pBest=new PsoValue(newFit, x); 


17 PBestMsg pBestMsg=new PBestMsg(pBest); 


18 getSender().tell(pBestMsg, getSelf()); 


20 } 

21 else{ 

22 unhandled(msg); 
23 } 

24 } 


上 述 代码 中 ， 粒 子 接收 到 了 全 局 最 优 (代码 第 4 行 )， 接 着 根据 粒 
子 群 的 标准 公式 更 新 目 己 的 速度 〈 第 6 一 8 行 ) 。 接 着 ， 根 据 速度 ， 更 新 
目 己 的 位 置 《第 10 一 12 行 ) 。 由 于 当前 问题 是 有 约束 的 ， 也 惑 是 说 解 空 
间 并 不 是 随意 的 。 粒 子 很 可 能 在 更 新 位 置 后 ， 跑 出 了 合理 的 范围 之 外 ， 
因此 ， 还 有 必要 进行 有 效 性 检查 (第 13 行 )。 


在 更 新 完成 后 ， 就 可 以 计算 新 位 置 的 适应 度 ， 如 果 产 生 了 新 的 个 体 
最 优 ， 就 将 其 发 送 给 Master 〈 第 15 一 19 行 ) 。 





在 当前 案例 中 ， 速 度 和 位 置 的 更 新 是 依据 标准 的 粒子 群 实现 ， 如 


F: 
01 public double updateVelocity(int i){ 

02 double v= Math.random()*velocity.get(i) 

03 +2*Math.random()*(pBest.getX().get(1)-x.get(i) ) 
04 +2*Math.random()*(gBest.getX().get(1)-x.get(i)); 
05 v=v>0? Math.min(v, 5): Math.max(v, -5); 

06 velocity.set(i, v); 

07 return V; 


09 
10 public double updateX(int i){ 


11 double newX=x.get(i)+velocity.get(i); 
12 x.set(i, newXx); 

13 return newXx; 

14 } 


上 述 代 码 中 updateVelocity0 和 updateX0 分 别 更 新 了 粒子 的 速度 和 位 
置 。 位 置 的 更 新 依赖 于 当前 的 速度 〈 第 11 行 ) 。 





由 于 每 一 年 的 投资 都 是 有 限额 的 ， 因 此 ， 要 避免 粒子 跑 到 合理 空间 
之 外 ， 下 面 的 代码 强制 将 粒子 约束 中 合理 的 区 间 中 。 


01 public void validatex(){ 


02 if(x.get(1)>400){ 

03 x.set(1, (double)r.nextInt(401)); 
04 } 

05 

06 //X2 

07 double max=400-1.1*x.get(1); 

08 if(x.get(2)>max || x.get(2)<0){ 
09 x.set(2, r.nextDouble()*max); 
10 } 

Ial //x3 

12 max=484-1.21*x.get(1)-1.1*x.get(2); 
13 if(x.get(3)>max || x.get(3)<0){ 
14 x.set(3, r.nextDouble()*max); 


15 了 


16 /1X4 


17 max=532.4-1.331*x.get(1)-1.21*x.get(2)-1.1*x.get(3); 
18 if(x.get(4)>max || x.get(4)<0){ 

19 x.set(4, r.nextDouble()*max); 

20 } 

21 } 


上 述 代码 分 别 对 x1、x2、x3、x4 进 行 约束 ， 一 旦 发 现 粒 子 跑 出 了 定 
义 范 围 就 将 它 进行 随机 化 。 


此 外 ， 我 们 还 需要 一 只 MasterBird， 用 于 管理 和 通知 全 局 最 优 。 


01 public class MasterBird extends UntypedActor { 








02 private final LoggingAdapter log = Logging.getLogger(getCo 
03 private PsoValue gBest=null; 

04 

05 @Override 

06 public void onReceive(Object msg) { 

07 if (msg instanceof PBestMsg) { 

08 PsoValue pBest = ((PBestMsg) msg).getValue(); 

09 if(gBest==null || gBest.value < pBest.value){ 

10 // 更 新 全 局 最 优 ， 通 知 所 有 粒子 

11 System.out.printin(msgt"\n"); 

12 gBest=pBest,; 

13 ActorSelection selection = getContext().actors 
14 selection.tell(new GBestMsg(gBest), getSelf()) 
15 } 


16 3 


17 elsef 


18 unhandled(msg); 


上 述 代码 定义 了 MasterBird。 当 它 收 到 一 个 个 体 最 优 的 解 时 ， 会 将 
其 与 全 局 最 优 进行 比较 ， 如 果 产 生 了 新 的 全 局 最 优 ， 束 更 新 这 个 全 局 最 
优 并 通知 所 有 的 粒子 〈 第 12 一 14 行 ) 。 








好 了 ， 现 在 万 事 俱 备 只 欠 东 风 。 下 面 就 是 主 函 数 : 


01 public class PSOMain { 


02 public static final int BIRD_COUNT = 100000; 

03 public static void main(String[] args) { 

04 ActorSystem system = ActorSystem 

05 .create("psoSystem", ConfigFactory.load("sampl 
06 system.actorOf(Props.create(MasterBird.class), "master 
07 for (int i = 0; i < BIRD_COUNT; i++) { 

08 system.actorOf(Props.create(Bird.class), "bird_" + 
09 } 

10 } 

cela 





上 述 代 码 定 义 了 粒子 总 数 ， 这 里 是 10 万 个 粒子 。 接 着 创建 一 人 1 
MasterBird Actor 〈 第 6 行 ) ， 和 10 万 个 bird〈 第 7~9 行 ) 。 


执行 上 述 代 码 ， 运 行 一 小 段 时 间 ， 你 就 可 以 得 到 如 下 输出 (截取 部 


ap) 


value: 36.15412875487459 
[-Infinity, 168.0, 18.786423873345715, 102.1742923174793, 76.5657 
value:37.88452477135976 


[-Infinity, 64.0, 87.66774733441137, 37.976681047619195, 206.1779 


value: 42.240797528048176 


[-Infinity, 113.0, 42.37168995110633, 141.70570102409184, 174.168 


value: 43 .01934824083668 
[-Infinity, 76.0, 112.89557345993592, 133.29270155682005, 147.162 


上 述 输 出 表示 ， 妆 粒子 群 随机 初始 化 时 ， 最 优 解 为 36.15 万 元 ， 但 
随 看 粒子 的 搜索 ， 这 个 投资 方 条 被 逐步 优化 ， 由 37.88 万 一 直上 升 到 
43.02 万 元 。 根 据 我 们 前 面 的 求解 ， 我 们 知道 这 个 投资 方案 的 最 优 结 
是 43.09 万 元 ， 可 以 看 到 ， 粒 子 群 的 搜索 结果 和 全 局 最 优 已 经 非常 接近 
To 


当然 了 ， 由 于 粒子 群 算法 的 随机 性 ， 每 次 执行 结果 可 能 并 不 一 样 ， 


这 意味 着 有 时 候 ， 你 可 能 会 求 得 更 好 的 解 ， 或 者 得 到 一 个 稍 差 一 些 的 
解 ， 但 其 偏差 不 会 相差 太 远 。 





7.14 参考 文献 


。 Akka 官 方 文档 

o http://doc.akka.io/docs/akka/2.3.7/java.html 
© 有 关 最 优化 方法 的 介绍 

o 《了 最 优化 方法 》 高 等 教育 出 版 社 施 光 燕 著 
e Nobody Needs Reliable Messaging 


o http://www. infoq.com/articles/no-reliable-messaging 


第 8 草 ”并 行程 友 调 试 








并 行程 友 调 试 要 比 串 行程 序 复 茶 得 多 ， 但 驻 运 的 是 ， 现 代 IDE 开 友 
环境 可 以 在 一 定 程度 上 组 建 并 发 程序 调试 的 难度 。 在 本 章 中 ， 我 想 简单 
介绍 一 下 有 关 并 行程 序 调试 的 一 些 技巧 和 经 验 。 


8.1 准备 实验 样本 


为 了 方便 讲解 ， 我 们 定义 一 个 简单 的 类 ， 作 为 实验 样本 : 


01 public class UnsafeArrayList { 


02 
03 
04 
05 
06 
07 
08 
09 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 


static ArrayList al=new ArrayList(); 
static class AddTask implements Runnable{ 
@Override 
public void run() { 
try { 
Thread.sleep(100); 
} catch (InterruptedException e) {} 
for(int i=0;i<1000000;i++) 
al.add(new Object()); 


} 
public static void main(String[] args) throws InterruptedE 
Thread ti=new Thread(new AddTask(),"t1"); 
Thread t2=new Thread(new AddTask(),"t2"); 
ti.start(); 
t2.start(); 
Thread t3=new Thread(new Runnable(){ 
@Override 
public void run() { 


while(true) { 


22 try { 
23 Thread.sleep(1000); 


24 } catch (InterruptedException e) {} 
26 } 


27 Pa ESNS 
28 t3.start(); 


在 这 里 ， 我 使 用 的 JDK 版 本 为 JDK8u5。 





上 述 代码 是 在 多 线程 下 访问 ArrayList， 因 此 ， 是 错误 的 写法 。 在 这 
里 ， 我 们 将 使 用 调试 ， 重 现 这 个 错误 。 


8.2 ”正式 起 航 


在 正式 开始 之 前 ， 先 让 我 们 熟悉 一 下 Eclipse 的 调试 环境 。 当 你 使 用 
Eclipse 调试 Java 程 序 时 ， 当 程序 执行 到 断 点 处 ， 默 认 情 况 下 ， 当 前 的 线 
程 就 会 被 挂 起 。 


图 8.1 显 示 了 在 ArrayListadd0 函 数 内 部 设置 了 一 个 断 点 : 


442= public boolean FEEKE e) { 

443 ensureCapacityInternal(size + 1); // Increments modCount!! 
444 elementData[size++] = e; 

445 return true; 

446 } 


图 8-1 将 断 点 设置 在 ArrayList. add () 内 


接着 ， 以 调试 方式 启动 上 面 的 代码 ， 可 以 看 到 ， 程 序 会 停留 在 系统 
第 一 次 调用 ArrayList.add0 的 地 方 ， 如 图 8.2 所 示 。 


4 D] UnsafeArrayList [Java Application] 
4 @& geym.conc.ch8.UnsafeArrayList at localhost:23564 
4 ¿® Thread [main] (Suspended (breakpoint at line 443 in ArrayList) 

@ owns: URLClassPath (id=23) 

@ owns: Object (id=24) 

& owns: Object (id=25) 
ArrayList<E>.add(E) line: 443 
URLClassPath.getLoader(int) line: 344 
URLClassPath.getResource(String, boolean) line: 198 
URLClassLoader$1.runQ line: 364 
URLClassLoader$1.runQ line: 361 
AccessController.doPrivileged(PrivilegedExceptionAction<T=, AccessControlContext) line: not availa 
Launcher$ExtClassLoader(URLClassLoader).findClass(String) line: 360 
Launcher$ExtClassLoader(ClassLoader).loadClass(String, boolean) line: 424 
Launcher$AppClassLoader(ClassLoader).loadClass(String, boolean) line: 411 
Launcher$AppClassLoader.loadClass(String, boolean) line: 308 
Launcher$AppClassLoader(ClassLoader).loadClass(String) line: 357 
LauncherHelper.checkAndLoadMain(boolean, int, String) line: 495 
pl D:\tools\jdk8u5\bin\javaw.exe (2015 年 5 月 9 日 下 午 1:02:19) 


图 8. 2 断 点 阻止 了 程序 的 运行 


TT Tn 1% M 








在 上 图 8.2 中 ， 可 以 看 到 主线 程 main 停 留 在 ArrayListadd0 中 ， 并 且 


显示 了 完整 的 调用 堆栈 。 但 很 不 幸 的 是 ， 其 实 我 们 对 主 函 数 并 没有 太 大 
兴趣 ， 因 为 这 些 都 是 JDK 内 部 的 代码 实现 。 目 前 ， 我 们 更 关心 的 是 在 程 
序 中 tL 和 t2 线 程 对 ArrayList 的 调用 。 因 此 ， 我 们 会 更 希望 忽略 这 些 无 关 
的 调用 。 对 于 ArrayList 这 种 非常 常用 的 类 来 说 ， 如 果 不 加 识别 地 进行 断 
点 设置 ， 对 系统 的 整个 调试 会 变 得 异常 痛 兰 。 那 么 应 该 怎么 处 理 呢 ? 


依托 于 Eclipse 的 强大 功能 ， 我 们 很 容易 实现 这 点 。 我 们 可 以 为 这 个 
晰 点 设置 一 些 额外 属性 ， 如 图 8.3 所 示 。 


i © Toggle Breakpoint Ctrl+Shift+B 
| Disable Breakpoint Shift+Double Click 


i Vv Show Line Numbers 


Folding 


Preferences... 


| Breakpoint Properties... Ctrl+Double Click 


图 8.3 设置 断 点 属性 





由 于 我 们 不 希望 主 函数 局 动 时 被 中 断 ， 因 此 在 条 件 断 点 中 指定 断 点 
条 件 是 当前 线程 而 不 是 主线 程 main， 如 图 8.4 所 示 ， 取 得 当前 线程 名 
称 ， 并 判断 是 否 为 主线 程 : 





I) Properties for java.util.ArrayList [line:443] - add(E) 

|| Line Breakpoint 
Type: java.util.ArrayList 
Line Number: 443 
Member: add(E) 


Breakpoint Properties 
Filtering 


| W] Enabled 


F] Hit count: @ Suspend thread © Suspend VM 














[V] Conditional @ Suspend when 'true' © Suspend when value changes 








<Choose a previously entered condition> 


(!(Thread.currentThread().getName().equals("main") + 














图 8.4 设置 条 件 断 点 


基于 以 上 设置 ， 再 次 执行 调试 这 段 代 码 ， 我 们 束 可 以 调试 L 和 t2 线 
程 了 ， 如 图 8.5 所 示 。 


4 O UnsafeArrayList [Java Application] 
4 g geym.conc.ch8.UnsafeArrayList at localhost:64528 
4 ® Thread [t2] (Suspended (breakpoint at line 443 in ArrayList) 
= ArrayList<E>.add(E) line: 443 
UnsafeArrayList$AddTask.run(Q line: 19 
Thread.run0 line: 745 
4 g® Thread [t1] (Suspended (breakpoint at line 443 in ArrayList)) 


= ArrayList<E>.add(E) line: 443 
UnsafeArrayList$AddTask.run( line: 19 
Thread.runQ) line: 745 

pS Thread [DestroyJavaVM] (Running) 
p® Thread [t3] (Running) 
pl D:\tools\jdk8u5\bin\javaw.exe (2015 年 5 月 9 日 下 午 5:14:25) 





图 8.5 被 中 断 的 t1 和 t2 


从 这 个 调试 窗口 中 可 以 看 到 ， 当 前 正在 执行 的 几 个 线程 ， 这 里 显示 
也 、 世 和 t3。 由 于 t3 线 程 并 没有 使 用 ArrayList， 因 此 ， 它 处 于 Running 


状态 ， 并 保持 一 直 执 行 。 而 tL 和 t2 两 个 线程 都 在 ArrayList.add() 方 法 中 被 
挂 起 。 


如 上 图 8.5 所 示 ， 妆 前 选中 的 是 t2 线 程 ， 如 果 我 们 进行 单 步 操作 ， 那 
么 2 线 程 就 会 执行 ， 而 { 不 会 继续 执行 ， 除 非 ， 你 手工 选择 tL 并 进行 相 
应 的 操作 。 


8.3” 挂 起 整个 虚拟 机 


在 这 里 ， 我 还 想 提 一 个 比较 重要 的 功能 。 在 默认 情况 下 ， 当 断 反 条 
件 成 立时 ， 系 统 会 挂 起 相关 的 线程 ， 没 有 断 点 的 线程 会 继续 执行 。 在 实 
际 环 境 中 ， 那 些 还 在 继续 执行 的 线程 可 能 会 对 整个 调试 产生 不 利 的 影 
啊 。 为 此 ， 我 们 可 以 设置 断 点 类 型 为 挂 起 整个 Java 虚 拟 机 ， 而 不 仅仅 是 
挂 起 相关 线程 。 如 图 8.6 所 示 ， 改 变 这 个 断后 的 类 型 : 


© Properties for java.util.ArrayList [line:443] - add(E) Ta 


type filter text Line Breakpoint 


Breakpoint Properties Type: java.util.ArrayList 


Line Number: 443 
Member: add(E) 


Filtering 


[Ñ] Enabled 


[F] Hit count: 5 Suspend thread] @ Suspend VM 


V| Conditional @ Suspend when ‘true’ Suspend when value changes 





| <Choose a previously entered condition> "| 





(!(Thread.currentThread() .getName() .equals("main") + 








图 8.6 设置 断 点 类 型 为 挂 起 整个 虚拟 机 


当然 ， 默 认 情 况 下 ， 调 试 器 只 会 挂 起 遇 到 断 点 的 线程 ， 如 果 你 希望 
所 有 断 点 的 模式 都 是 挂 起 虚拟 机 而 不 是 挂 起 线程 ， 则 还 可 以 在 Eclipse 的 
全 局 配置 中 设置 ， 如 图 8.7 所 示 。 





Debug 


> General General settings for Java Debugging. 


> Ant 
> Data Management See ‘Run/Debug' for general debug settings. 


> Help Suspend Execution 





> Install/Update 三 V] Suspend execution on uncaught exceptions 








4 Java V] Suspend execution on compilation errors 
> Appearance 回 Suspend for breakpoints during evaluations 
> Build Path e Open popup when suspended on exception 


> Code Styl 
se a ye Default suspend policy for new breakpoints: [Suspend vm 7] 
> Compiler Thread 
Default suspend policy for new watchpoints: [Suspend ww | 


> Editor 
> Installed JREs Hot Code Replace 





























JUnit Show error when hot code replace fails 





Properties Files Ec [V] Show error when hot code replace is not supported 














> Java EE X V] Show error when obsolete methods remain after hot code replace 


| m Loge — . 二 





[ox J [cancel | 
图 8.7 设置 断 点 模式 行为 为 挂 起 虚拟 机 








在 挂 起 虚拟 机 模式 下 ， 程 序 进 入 断 点 后 的 状态 如 图 8.8 所 示 。 


4 D] UnsafeArrayList Java Application] 
4 只 geym.conc.ch8.UnsafeArrayList at localhost:65475 (Suspended) 
> gf Daemon System Thread [Attach Listener] (Suspended) 
> gi Daemon System Thread [Signal Dispatcher] (Suspended) 
>` g® Daemon System Thread [Finalizer] (Suspended) 
> gf Daemon System Thread [Reference Handler] (Suspended) 
4 a Thread [t1] (Suspended (breakpoint at line 443 in ArrayList) 





= Arraylist<E>.add(E) line: 443 | 
= UnsafeArrayList$AddTask.runO line: 19 
= Thread.runQ line: 745 
> g® Thread [t2] (Suspended) 
> g® Thread [DestroyJavaVM] (Suspended) 
> g® Thread [t3] (Suspended) 
pAl_D:\tools\jdk8u5\bin\javaw.exe (2015 年 5 月 9 日 下 午 5:20:46) 





图 8.8 挂 起 虚拟 机 时 的 系统 状态 


可 以 看 到 ， 妆 前 所 有 的 线程 全 部 处 于 挂 起 状态 ， 不 论 当 前 线程 是 否 
接触 到 了 断 点 。 这 种 模式 可 以 排除 其 他 线程 对 被 调试 线程 的 干扰 。 当 
然 ， 使 用 这 种 方法 有 时候 会 引起 调试 器 或 者 虚拟 机 的 一 些 问题 ， 导 致 系 
统 不 能 正常 工作 。 


直接 执行 上 述 代码 ， 很 可 能 抛 出 类 似 下 面 的 卉 常 : 


Exception in thread "t2" java.lang.ArrayIndexOutOfBoundsException 
at java.util.ArrayList.add(ArrayList.java:444) 
at geym.conc.ch8.UnsafeArrayList$AddTask.run(UnsafeArrayList. 


at java.lang.Thread.run(Thread. java: 745) 





下 面 ， 就 让 我 们 用 单 步调 试 的 方法 ， 来 重 现 这 个 异常 吧 ! 


8.4 WAHA A ArrayList A 部 


首先 ， 我 们 需要 理解 ArrayList 的 工作 方式 。 在 ArrayList 初 始 化 时 ， 
默认 会 分 配 10 个 数组 空间 。 当 数组 空间 消耗 完毕 后 ，ArrayList 就 会 进行 
目 动 扩容 。 在 每 次 add0 操 作 时 ， 系 统 总 要 事先 检查 一 下 内 部 空间 是 合 满 
足 所 需 的 大 小 ， 如 果 不 满足 ， 残 会 扩容 ， 否 则 就 可 以 正常 添加 元 素 。 











多 线程 共同 访问 ArrayList 的 问题 在 于 : 在 ArrayList 容 量 快 用 完 时 
《只 有 1 个 可 用 空间 ) ， 如 果 两 个 线程 同时 进入 add() 函 数 ， 并 同时 判断 
认为 系统 满足 继续 添加 元 对 而 不 需要 扩容 ， 进 而 两 者 都 不 会 进行 扩容 操 
作 。 之 后 ， 两 个 线程 先后 同系 统 写 入 自己 的 数据 ， 那 么 必然 有 一 个 线程 
会 将 数据 写 到 边界 外 ， 而 产生 这 个 ArrayIndexOutOfBoundsException。 





基于 上 述 原理 ， 我 们 在 ArrayList.addO 〇 函数 中 设置 断 点 如 图 8.9 所 
示 。 


Line Breakpoint 
Type: java.util,ArrayList 


Une Number 443 
Member: add(E) 


[V] Enabled 
-| Hit count: © Suspend thread Suspend VM 
V| Conditional @ Suspend when ‘true’ Suspend when value changes 


<Choose a previously entered condition> ’ 





((! (Thread. currentThread().getName().equals("main"))) «< 
&& size== 9) 





图 8.9 ArrayList. add() 的 断 点 设置 











这 个 断 点 意味 着 在 非 主 线程 中 〈 这 里 就 是 4 和 t 志 了 ) ， 当 进入 add0) 





函数 后 ， 如 果 当 前 ArrayList 的 容量 为 9〈“ 当 前 的 最 大 容量 为 10) ， 则 触 
发 断 点 。 之 所 以 这 么 设置 ， 是 因为 当 容 量 没有 饱和 时 ， 显 然 不 会 发 生 这 
个 ArrayIndexOutOfBoundsException 的 问题 ， 因 此 可 以 直接 忽略 这 些 情 
Hlo 





接着 ， 选 中 tl 线程， 让 它 进行 容量 检查 ， 并 让 它 停止 在 追加 元 素 的 
语句 前 ， 如 图 8.10 所 示 。 


¥ Debug 3 
4 O UnsafeArrayList Java Application] 
4 从 geym.conc.ch8.UnsafeArrayList at localhost:5732 
4 g Thread [t2] (Suspended (breakpoint at line 443 in ArrayList)) 
= ArrayList<E>.add(E) line: 443 
= UnsafeArrayList$AddTask.run(Q line: 19 
三 Thread.runQ line: 745 
4 ¿® Thread [t1] (Suspended) 
= UnsateArrayLlist$Ada 了 - 
三 Thread.run0 line: 745 
p® Thread [t3] (Running) 
p® Thread [DestroyJavaVM] (Running) 


网 was Pst thew me” rns rrr OAM Tier ra amn 


WD UnsafeArrayListjava fon ArrayList.class 33 | $ip Thread.class Tip AbstractList.class 
/[** 
* Appends the specified element to the end of this list. 
* 
* param e element to be appended to this list 
* @return <tt>true</tt> (as specified by {@link Collection#add}) 
+f 
public boolean add(E e) { 
ensureCapacityInternal(size + 1); // Increments modCount!! 
elementData[size++] =e; 在 这 于 停 下 
return true; 





图 8. 10 t1 线 程 完成 容量 检查 


alt 


接着 ， 在 t1 增 加 元 素 之 前 ， 选 中 了 2 线程 ， 并 让 忆 进 入 add0) 函 数 ， 
成 进行 容量 检查 ， 如 图 8.11 所 示 。 


4 回 ee rr Uava Application] 
4H ei at localhost:5732 


= UnsafeArraylist$AddT mr line: 19 
三 Thread.run0 line: 745 
4 0 Thread [t1] (Suspended) 

= ArrayList<E>.add(E) line: 444 
= UnsafeArrayList$AddTask.runQ line: 19 
= Thread.run(Q line: 745 

p® Thread [t3] (Running) 

只 — [DestroyJavaVM] (Running) 


Mans 6 ue Gos ous? oe paneer BAN Ther ra an 


QB) UnsafeArrayList.java “fy Arraylist.class 3 x E Thread.class Ti AbstractList.class 


容量 检查 完成 





图 8. 11 t2 完 成 容量 检查 


此 时 ，tL 和 t2 都 认为 ArrayList 中 的 容量 是 满足 它们 的 需求 的 ， 因 
此 ， 它 们 都 准备 开始 追加 元 素 。 让 我 们 先 选择 t1， 完 成 追加 ， 如 图 8.12 
所 示 。 


$s Debug 3 
4 O UnsafeArrayList [Java Application] 
4 & geym.conc.ch8.UnsafeArrayList at localhost:5732 
4 gi Thread [t2] (Suspended) 
= ArrayList<E>.add(E) line: 444 
UnsafeArrayList$AddTask.runQ line: 19 
= Thread.run( line: 745 
4 gi Thread [t1] (Suspended) 
= UnsateArrayList$AddTask.runQ line: 19 
= Thread.run0 line: 745 
p® Thread [t3] (Running) 
p? — ee (Running) 


mM mae st ta ese ` nner OAM Ther ra amn 


四 UnsafeArrayListjava fen) ArrayList.class 33 | $ip Thread.class by AbstractList.class 


436- [z= 
437 * Appends the specified element to the end of this list. 
438 * 
439 * @param e element to be appended to this list 
440 * @return <tt>true</tt> (as specified by {@link Collection#add} 
441 */ 
442- public boolean add(E e) { 
2: 443 ensureCapacityInternal(size + 1); // Increments modCount!! 


444 elementData[size++] = e; 
> 445 return true; 
AAG 


图 8.12 t1 完 成 元 素 追 加 











在 tl 退 加 完成 后 ， 纪 并 不 知道 数据 空间 实际 上 已 经 用 完了 。 而 之 前 
的 容量 检查 告诉 2， 你 可 以 继续 妃 加 元 素 ， 因 此 ，t2 还 会 义无反顾 地 继 
续 执行 后 续 仍 加 操作 。 选 择 t2， ee 此 时 ， 当 t2 试 图 向 
ArrayList 仍 加 元 素 时 ， 妃 加 操作 并 没有 如 我 们 预期 一 样 完成 ， 因 为 ， 此 
时 ，size 的 值 已 经 超过 了 elementData 的 边界 。 13 所 示 ， 可 以 看 到 
ArrayIndexOutOfBoundsException 异 常 位 于 t2 线 程 中 。 


¥ Debug x #4 Servers 
a 加 UnsafeArrayList [Java Application] 
4 @& geym.conc.ch8.UnsafeArrayList at localhost:5732 


= Thread.run( line: 745 
4 只 Thread [t1] (Suspended) 
= ArrayList<E>.add(E) line: 445 
= UnsafeArrayList$AddTask.runQ line: 19 
= Thread.run0 line: 745 
p® Thread [t3] (Running) 
p® Thread [DestroyJavaVM] (Running) 


Mans 





A8.13 t2 线 程 发 生 异常 





让 t2 继 续 往 下 执行 的 结果 就 是 前 文中 那 段 异常 信息 ， 之 后 ， 包 线程 
就 从 线程 列表 中 消失 了 执行 结束 〉。 


